Coming from Firebase

If you build on Firebase, you already know how Plexivo Postgres works as a backend: your app talks to it directly, users sign in, rules decide who sees what, and changes arrive live. The difference is underneath. Your data lives in PostgreSQL tables, so you get joins, transactions, constraints and SQL, and it runs in Mumbai, with backups copied to Hyderabad.

The same ideas, mapped#

Code, side by side#

Set up#

// Firebase
const app = initializeApp(firebaseConfig);
const auth = getAuth(app);
const store = getFirestore(app);

// Plexivo
const db = createClient(PLEXIVO_DATA_URL, PLEXIVO_PUBLISHABLE_KEY);

Sign up#

// Firebase
await createUserWithEmailAndPassword(auth, email, password);

// Plexivo
await db.auth.signUp({ email, password });

Write#

// Firebase
await addDoc(collection(store, 'notes'), {
  owner: auth.currentUser.uid, body: 'Hello', createdAt: serverTimestamp()
});

// Plexivo: owner and created_at fill themselves in (column defaults)
await db.from('notes').create({ body: 'Hello' });

Read#

// Firebase
const q = query(collection(store, 'notes'),
  where('owner', '==', auth.currentUser.uid),
  orderBy('createdAt', 'desc'), limit(20));
const snap = await getDocs(q);

// Plexivo: the policy already limits rows to the signed-in user
const notes = await db.from('notes').order('created_at', 'desc').limit(20);

Listen for changes#

// Firebase
onSnapshot(q, (snap) => snap.docChanges().forEach((c) => render(c.type, c.doc.data())));

// Plexivo
db.channel('changes:notes')
  .onChange(({ type, record }) => render(type, record))
  .subscribe();

Switch on Realtime for the table on the database’s Data API tab first.

Rules become policies#

-- Firebase Security Rules:
--   match /notes/{id} {
--     allow read, update, delete: if request.auth.uid == resource.data.owner;
--     allow create: if request.auth.uid == request.resource.data.owner;
--   }

-- Plexivo Postgres
alter table notes enable row level security;
create policy "Each user owns their notes" on notes
  for all to authenticated
  using (owner = auth.uid())
  with check (owner = auth.uid());

Call a function#

// Firebase
const { data } = await httpsCallable(functions, 'sendReceipt')({ orderId });

// Plexivo
const { data } = await db.functions.invoke('send-receipt', { body: { orderId } });

Flutter developers use plexivo_client the same way.

Move your app#

1. Create the backend. Follow Build a backend in minutes: a database, the Data API and the sign-in methods you use today.
2. Design your tables. Give each collection a table and each field a column with a type. Turn subcollections into tables with a foreign key, and keep free-form maps in jsonb. Wherever a rule checks the user, add an owner uuid default auth.uid() column, so new rows belong to whoever creates them.
3. Write the policies. Translate each Security Rule into a policy, as above. A table is reachable from your app only once it has row-level security and a policy.
4. Bring your users. Import them by email from your server with the secret key, up to 1,000 per call, with a bcrypt password hash where you have one. Users without one sign in with an email code or set a new password through password recovery. Firebase user ids are not UUIDs, so each imported user gets a new id; map their old Firebase id to it as you load their data.
5. Load your data. Export your collections to JSON and insert the rows from your server with the secret key, for example with createInBatches.
6. Move your functions. Rewrite each Cloud Function as a Plexivo Function and give it its secrets on the database’s Functions tab.
7. Switch the app. Replace the Firebase calls with the Plexivo client, test with real accounts, then release.

Next steps#