How to Sync Billing Data to Prisma Postgres (Stripe, QuickBooks, Xero & Paddle)

Sync Stripe, QuickBooks, Xero or Paddle into Prisma Postgres. Which connection string to use, how a batched sync counts operations, and what it costs.

By Ilshaad Kheerdali · 14 November 2026

Most usage-priced databases make you ask an awkward question before you add a data pipeline: how much will all that background work cost? On a database billed for compute time, a long-running sync keeps the meter going for as long as it runs.

Prisma Postgres counts something different. It bills per operation, not per query duration, and a scheduled batch sync is a small number of large batched upserts rather than a stream of small queries. That makes the two a good fit. This guide covers how to get Stripe, QuickBooks, Xero or Paddle data into Prisma Postgres, which connection string to use, and how many operations to expect.

Why Prisma Postgres Fits a Scheduled Billing Sync

Billing data is usually small (most SaaS companies are talking about thousands of rows, not millions), it tends to change slowly, and it only needs refreshing on a schedule. What matters for the bill is how that work reaches the database.

Here is how Prisma describes its billing: "A read or a write, simple or complex, counts as one operation," and cost is "based solely on the number of operations, not the amount of compute required to execute them." Storage is billed separately, and data transfer is unlimited on every plan.

The current plans:

Codeless Sync writes one multi-row INSERT ... ON CONFLICT DO UPDATE statement per page of records it fetches from your billing provider. For most data types that page is 100 records, so 100 invoices is one SQL statement, not 100.

Create a Prisma Postgres Database

If you already have a database, skip to the next section.

1. Sign in to the Prisma Console and start a new database.
2. Give it a name, then click Get started under Prisma Postgres.
3. Choose a region. Prisma currently offers San Francisco, North Virginia, Paris, Frankfurt, Tokyo and Singapore. Pick carefully, because you can't change the region afterwards.

You can also create a database from the command line with npx prisma postgres create mydb.

If you use Prisma Migrate in your application, consider giving billing data its own database. Synced tables are created outside your migrations, and Prisma's docs list changing a schema without migrations as a cause of schema drift.

Which Prisma Postgres Connection String to Use

To get your connection string, open the database in the Console and click Connect to your database. On an existing database, you may also need to click Generate new connection string. Prisma gives you two standard Postgres strings, and the Connection pooling switch chooses between them: on for pooled, off for direct. The only difference is the host:

# Pooled (recommended) postgres://USER:PASSWORD@pooled.db.prisma.io:5432/postgres?sslmode=require # Direct (also works) postgres://USER:PASSWORD@db.prisma.io:5432/postgres?sslmode=require 

We tested both end to end with Codeless Sync, and both work. Use the pooled string unless you have a reason not to:

• Pooled is what Prisma recommends for all application traffic, and it names background workers specifically, which is what a scheduled sync is. Pooled queries are limited to 10 minutes, which is far longer than one batched write needs.
• Direct also works, but direct connections are in shorter supply: 10 on the Starter plan against 100 pooled. Prisma points migrations, pg_dump and GUI tools such as TablePlus and DBeaver at the direct string, so it makes sense to leave those slots for them.

Both strings use sslmode=require, so the connection is encrypted (SSL).

Each time you generate a string, Prisma creates a new credential, and older ones keep working. Prisma advises giving each app or service its own, so you can delete one app's password without breaking the others. It makes sense to generate one just for Codeless Sync. Every credential has full access to its database, because Prisma Postgres does not currently offer read-only or per-table credentials.

If a string is not behaving, paste it into our free PostgreSQL connection string validator. It recognises both Prisma Postgres hosts and tells you whether you are on the pooled or direct connection.

Connect Prisma Postgres to Codeless Sync

In Codeless Sync, create a new sync configuration and choose your billing provider and data type. Customers (Contacts on Xero) is the easiest to eyeball first. On the database step:

1. Give the project a name. If you already have projects, click Create New Project first.
2. Choose Prisma Postgres as the database platform.
3. Paste your connection string.
4. Click Test & Continue.

The connection is tested before you can continue, so you find out immediately if something in the string is wrong. There is more detail in the database setup guide.

Connect Your Billing Provider and Run the First Sync

Next, authorize the provider you want to pull from:

• Stripe and Paddle use an API key. For Stripe, use a restricted key with read-only permissions rather than your secret key.
• QuickBooks and Xero use OAuth, so you approve access on their consent screen and never handle a token yourself.

Click Auto-create Table to create the destination table in your database, name the configuration, and run the sync. The full walkthrough with screenshots lives in the quick start guide if you want it step by step.

The table naming is predictable: stripe_customers, quickbooks_invoices, xero_contacts, paddle_subscriptions, and so on. Each provider gets its own tables, so you can run several providers into one database without them colliding.

How Many Operations Will a Sync Use?

A batch sync costs a handful of operations, not one per row. We measured this on a real database: a 375-row Stripe payment_intents sync used 15 operations in the Prisma Console's usage chart, including setup queries such as table and schema checks. Written one row at a time, the same sync would have needed at least 375. To see your own count, open the database's Dashboard in the Prisma Console and hover over the daily bars in the usage chart.

The count grows with the number of batches rather than the number of rows, plus a small overhead. Most data types write up to 100 rows per batch, though Paddle's page sizes vary by data type. Even the Free plan's 200k operations is far more than a test sync needs; for production, Starter's 1M is the realistic baseline.

One caveat: if a whole batch fails, Codeless Sync retries those records one at a time, so that batch costs at least one operation per record instead of one in total.

The bigger number is usually your own traffic. Every query counts, so a single dashboard widget that runs one query a minute is about 43,200 operations a month, far more than a scheduled sync needs. If you put a BI tool on this data, its refresh interval is the setting to check first.

Query Your Billing Data

The tables are ordinary Postgres, so anything that speaks Postgres can read them. Prisma's docs list psql, Drizzle, Kysely, TypeORM and the Prisma ORM. You do not need the ORM for any of this. For psql and GUI tools, Prisma says to use the direct string.

To see how much storage the sync is using, ask Postgres directly:

SELECT relname AS table_name, to_char(n_live_tup, 'FM999,999,999') AS approx_rows, pg_size_pretty(pg_total_relation_size(relid)) AS total_size FROM pg_catalog.pg_stat_user_tables WHERE relname LIKE 'stripe\_%' OR relname LIKE 'quickbooks\_%' OR relname LIKE 'xero\_%' OR relname LIKE 'paddle\_%' ORDER BY pg_total_relation_size(relid) DESC; 

One caveat: n_live_tup is an estimate, so straight after a first sync it can still read zero. The size column is the one to trust. The JSONB column holding the original API object can take up a lot of the space, so measure this on your own data rather than guessing, and compare it with your plan's storage allowance.

Since each provider has its own tables, you can also query across them. This one shows what customers owe you across Stripe and Xero, and it counts as a single operation:

SELECT 'stripe' AS source, UPPER(currency) AS currency, COUNT(*) AS open_invoices, SUM(amount_due) / 100.0 AS amount_due FROM stripe_invoices WHERE status = 'open' AND livemode GROUP BY UPPER(currency) UNION ALL SELECT 'xero', UPPER(currency_code), COUNT(*), SUM(amount_due) FROM xero_invoices WHERE type = 'ACCREC' AND status = 'AUTHORISED' AND livemode GROUP BY UPPER(currency_code) ORDER BY source, currency; 

Stripe stores amounts in the smallest currency unit, which is why that side divides by 100. Zero-decimal currencies such as JPY need handling separately. For more, How to Calculate MRR, Churn, and LTV in PostgreSQL has the SQL for the usual revenue metrics.

If you want to build something on top of these tables, such as an internal revenue dashboard, Prisma Compute can host the TypeScript app (Node.js, Bun or Next.js) alongside your Prisma Postgres database.

What This Actually Costs End to End

Putting the two halves together:

The Codeless Sync price is flat: a sync that reaches the monthly row limit stops rather than adding a charge. On the table above the sync stays well inside Prisma's included operations, so a busy billing month does not move either number. What can move the Prisma side is your own query traffic and storage past the included amount, and Prisma lets you set a spend limit on any paid plan to cap that.

The free setup is only for trying this out. Prisma says its Free plan is "intended for evaluation only and is not meant for production workloads," and it has no backups. When a Free database runs out of operations, it stops accepting read and write requests until you upgrade or the allowance resets at the start of the next month. Your data is not deleted, and you can restore access for 24 hours from the Console. That grace period is available once per workspace and doesn't renew each month.

Keeping It Current

A one-off sync is enough to explore. For anything you actually depend on, put it on a schedule so nobody has to remember it.

Scheduled syncs are a paid feature. When you create a schedule you also pick the sync mode: a full sync, which is the default and re-reads everything, or a fixed window covering the last day, 7 days or 30 days. For QuickBooks, Xero and Paddle transactions the window picks up records updated in that period; for Stripe it picks up records created in it, so an occasional full sync is what catches older Stripe records that changed. A window writes fewer rows, which uses fewer operations and less of your row allowance, and a daily schedule pairs best with the last-7-days window, so one failed run heals itself on the next.

Different providers can run at different cadences. Stripe daily and QuickBooks invoices weekly is a reasonable split, since invoices usually don't change often enough to justify more. Schedules can run daily, weekly or monthly, plus 12-hourly on the Business plan, and how often to sync billing data covers how to choose.

Frequently Asked Questions

Should I use the pooled or direct connection string?

Use the pooled string (pooled.db.prisma.io). Both work with Codeless Sync, and we tested both end to end, but pooled is what Prisma recommends for application traffic and it leaves your limited direct connections free for tools like pg_dump.

Will a sync use up my Prisma Postgres operations?

Not on its own. Codeless Sync writes in batches rather than row by row: in our test, a 375-row Stripe sync used 15 operations, including setup queries such as table and schema checks. Your own application and dashboard queries are far more likely to be what uses up your allowance.

Is the connection encrypted?

Yes. Both connection strings use sslmode=require, so the connection is encrypted (SSL).

Do I need the Prisma ORM?

No. Prisma Postgres is a standard Postgres database with a standard connection string. Codeless Sync connects to it directly, and you can query the synced tables with any Postgres client, with or without the ORM.

Can I sync more than one billing provider into the same database?

Yes. Each provider writes to its own prefixed tables (stripe_, quickbooks_, xero_, paddle_), so they coexist in one database and can be joined together in a single query.

What happens if my Free database runs out of operations?

Prisma says it stops accepting read and write requests, so syncs would fail too, until you upgrade or the allowance resets at the start of the next month. Your data is not deleted. Paid Prisma plans charge for extra operations instead, at $8 per million on Starter, and you can set a spend limit to cap that.

Wrapping Up

A scheduled billing sync suits Prisma Postgres because it does a lot of work in a small number of statements, and Prisma bills per operation, not for compute time. Pick the pooled connection string, choose your provider, and the data lands as ordinary tables you can query with the tools you already use.

If you are still choosing a host, our Prisma Postgres vs Supabase vs Neon vs Railway comparison covers how each one bills.

Try it at codelesssync.com

Related:

• Prisma Postgres vs Supabase vs Neon vs Railway (2026)
• Database Setup Guide
• How Often Should You Sync Billing Data to Postgres?
• How to Fix a PostgreSQL Connection String That Won't Connect
• Free PostgreSQL Connection String Validator