Firebase vs PostgreSQL

Quick verdict

Firebase is Google's app development platform, and this page is about its databases. Cloud Firestore describes itself as a NoSQL, document-oriented database: documents of fields, grouped into collections, with optional subcollections. It comes in a Standard edition and an Enterprise edition; Enterprise adds Pipeline operations, optional indexes, text search and a MongoDB-compatible API. The Realtime Database is Firebase's original database, which stores data as one JSON tree; Google labels Firestore as the preferred choice for new projects. Firebase also offers SQL Connect (formerly Data Connect), which runs on Cloud SQL for PostgreSQL and is covered below.

PostgreSQL is an open source object-relational database under the PostgreSQL Licence. It is software, not a service: you run it on your own servers or containers, or rent it as a managed service such as Cloud SQL for PostgreSQL, AlloyDB, Amazon RDS, Supabase or Neon. The current stable release on postgresql.org is 18.6.

The two differ in kind as well as model. Firestore is a serverless database designed to be called from client apps; PostgreSQL is a database server that applications reach through a backend or an API layer. This page compares them as databases. For the backend platform comparison (auth, storage, functions) see Supabase vs Firebase, and for the modelling question see Relational vs Document Database.

Side by side

Key differences

Data model and querying

Firestore is schemaless: Google's data model page says you have complete freedom over the fields and types in each document. Queries filter and order documents in one collection (or a collection group). In Standard edition, indexes are required for every query; single-field indexes are created automatically and composite indexes must be defined. The documented limits include up to 30 equality clauses combined in an in filter and up to 10 in a not-in filter. There are no joins, so related data is denormalised into documents or fetched with extra reads.

Aggregation in Standard edition means count(), sum() and average() over the results of a query, which Google notes saves billed reads compared with downloading the documents. A "revenue per country" report therefore needs one aggregation query per country or totals you maintain yourself. Enterprise edition's Pipeline operations add further aggregation and string-matching operators.

// Firestore (modular web SDK): one figure for one filter
import { collection, query, where, getAggregateFromServer,
         count, sum } from "firebase/firestore";

const q = query(collection(db, "orders"),
                where("country", "==", "GB"),
                where("status", "==", "shipped"));
const snap = await getAggregateFromServer(q, {
  orders: count(),
  revenue: sum("total")
});
console.log(snap.data().orders, snap.data().revenue);

-- PostgreSQL: every country at once, joining customers to orders
SELECT c.country,
       count(*)     AS orders,
       sum(o.total) AS revenue
FROM   orders o
JOIN   customers c ON c.customer_id = o.customer_id
WHERE  o.status = 'shipped'
GROUP  BY c.country
ORDER  BY revenue DESC;

In our assessment this is the decisive difference for most teams: Firestore works well when each screen maps to a known query, while PostgreSQL also answers the questions you did not plan, which is where reporting and back-office work usually go. See SQL vs NoSQL for the wider trade-off.

Who talks to the database, and how it is secured

Firestore is designed to be called from the app itself. Google's documentation states that every request from a Firestore mobile or web client library is evaluated against your Security Rules before any data is read or written, while server client libraries bypass Security Rules and authenticate with Google Application Default Credentials and IAM. Your rules are therefore the security boundary for client access, and they must be written and tested as carefully as server code.

PostgreSQL expects connections from trusted servers. A typical design puts an API between the app and the database, which holds credentials and enforces access. PostgreSQL also offers row security policies: once row level security is enabled on a table, the documentation describes a default-deny behaviour when no policy applies, and policies decide which rows each role can see or change. API layers such as PostgREST (used by Supabase) rely on these policies to expose PostgreSQL more directly.

-- PostgreSQL: each signed-in role sees only its own orders
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY own_orders ON orders
  FOR SELECT
  USING (owner_name = current_user);

Realtime updates and offline use

Firestore clients can attach realtime listeners to a document or query and are notified when the results change. Offline persistence is enabled by default on Android and Apple platforms and disabled by default on the web; when enabled, the SDK caches the data the app is actively using and syncs local changes when the device reconnects. Google documents some limits: Pipeline operations do not work offline, and transactions fail when the client is offline. The Realtime Database also syncs to clients, with offline support on Apple and Android only.

PostgreSQL has server-side building blocks rather than client sync: LISTEN and NOTIFY for notifications between sessions, and logical replication for streaming row changes. Pushing changes to browsers or phones, and letting them work offline, needs additional software (for example Supabase Realtime for change notifications, or a third-party sync layer). If offline-first mobile behaviour is a core requirement, Firestore provides it out of the box.

Consistency, transactions and limits

Firestore replicates data synchronously across zones using Paxos, and Google documents that reads return the latest version of the data. Transactions read and then write, never apply partially, and are retried automatically on conflict (optimistic concurrency); batched writes group several writes atomically without reads. Documented limits include a maximum document size of 1 MiB, nesting of up to 20 levels in maps and arrays, and 40,000 index entries per document.

PostgreSQL runs every statement in an ACID transaction under multiversion concurrency control, offers isolation levels up to serializable, and enforces types, NOT NULL, CHECK, unique and foreign key constraints, so invalid or orphaned data is rejected by the database rather than by application code or rules.

Scaling and operations

Firestore needs no capacity planning: Google's comparison page says it scales automatically with no limit on concurrent connections. The Realtime Database is different: Google states it scales to around 200,000 concurrent connections and 1,000 writes per second in a single database, beyond which you shard across several databases. Firestore is available only as a Google service, with no self-hosted version.

PostgreSQL scales up on one primary, adds read replicas through streaming replication, and scales out through extensions such as Citus. Each client connection is a server process, so applications with many short-lived connections, such as serverless functions, usually add a connection pooler. Managed services take over backups, patching and failover, and because PostgreSQL is the same engine everywhere you can change provider; see Supabase vs Neon, Supabase vs AWS RDS and Google Cloud SQL vs AlloyDB.

PostgreSQL inside Firebase: SQL Connect

If you want Firebase's SDKs and tooling with a relational database, Firebase SQL Connect (renamed from Data Connect, with unchanged APIs) is built on Cloud SQL for PostgreSQL. You define a schema and operations in GraphQL, Firebase generates typed SDKs for Android (Kotlin), iOS, Flutter and the web, and the documentation also covers implementing operations in native SQL. This gives a real PostgreSQL database under a Firebase project, but clients use generated operations rather than ad hoc queries. Firestore Enterprise edition's MongoDB compatibility is a separate option for teams with MongoDB code and tools.

Pricing and licensing

Cloud Firestore. Listed in the Firebase documentation and pricing page in October 2026. The no-cost quota for Standard edition is 1 GiB stored, 50,000 document reads, 20,000 writes and 20,000 deletes per day, and 10 GiB of outbound transfer per month, for one database per project. Beyond that, on the pay-as-you-go Blaze plan, Firestore charges for documents and index entries read to satisfy a query, for each write and delete, and for stored data, at prices that vary by location (published on the Google Cloud Firestore pricing page). Enterprise edition is priced separately. Because billing follows operations, the cost of a screen depends on how many documents it reads.

Firebase SQL Connect. According to Firebase's SQL Connect pricing page, the Blaze plan includes 250,000 operations per month at no cost, then USD 0.90 per million operations, plus the underlying Cloud SQL instance, which Firebase says starts at USD 9.37 per month depending on region and configuration. Qualifying accounts get a three-month no-cost Cloud SQL trial.

PostgreSQL. The software is free under the PostgreSQL Licence. You pay for the servers you run it on or for a managed service, which providers price by instance size, storage, I/O and region; there is no single list price to quote.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want PostgreSQL with built-in auth, storage and client libraries: compare the platforms in Supabase vs Firebase and see Firebase alternatives.
• You want a document database you can self-host or run on several clouds: see MongoDB vs PostgreSQL.
• You are on AWS and want a serverless key-value store: see DynamoDB vs PostgreSQL.
• An app that needs a local database on the device: an embedded database such as SQLite fits; see SQLite vs PostgreSQL.

Final recommendation

Frequently asked questions

Sources

• Cloud Firestore documentation
• Cloud Firestore: Data model
• Cloud Firestore: Editions
• Cloud Firestore: Simple and compound queries
• Cloud Firestore: Aggregation queries
• Cloud Firestore: Transactions and batched writes
• Cloud Firestore: Access data offline
• Cloud Firestore: Security Rules
• Cloud Firestore: Understand reads and writes at scale
• Cloud Firestore: Usage and limits
• Cloud Firestore: Billing
• Firebase: Choose a database (Realtime Database vs Cloud Firestore)
• Firebase SQL Connect documentation
• Firebase SQL Connect pricing
• Firebase pricing
• PostgreSQL documentation: Row security policies
• PostgreSQL documentation: NOTIFY
• PostgreSQL documentation: Transaction isolation
• PostgreSQL Licence

Checked October 2026.

How we research comparisons: our editorial method.