Use DuckDB when the job is analysing large files or tables on one machine, for example aggregations inside Python or R, with nothing to install or run. Use PostgreSQL when an application needs a long-running, multi-user database with replication, access control and a wide feature set, including your own data types and functions.
Both of these speak SQL and both are open source, which is why they end up on the same shortlist. The people searching this are usually developers or analysts with a data project in front of them: a pile of exports to crunch, a dashboard to feed, or an app that needs somewhere to keep its records. The decision comes down to two things, where the database runs and what kind of queries you throw at it, and the sections below take each in turn.
The in-process story has a twist
DuckDB's own explainer page says that, out of the box, it lives inside whatever program calls it rather than as a separate service. Your Python script, notebook or application carries the database along with it. That has long been its headline difference from a server.
The same page adds that, having adopted in-process operation, the project later stepped out of it through what it calls the Quack protocol. So if you ruled it out in the past because it couldn't be reached as a separate service, that picture has changed. Read the Quack documentation before you design around it.
PostgreSQL works the other way round. It's the kind of database you keep running as a long-lived server that many users and applications connect to at once. Its feature list includes replication and write-ahead logging.
Feature by feature
| DuckDB | PostgreSQL | |
|---|---|---|
| Model | Relational, SQL | Object-relational, extends SQL |
| Runs as | Embedded, plus Quack | Server |
| Workload | Analytical (OLAP) | Not listed |
| ACID | Yes, own MVCC | Since 2001 |
| External dependencies | None | Not listed |
| Custom types and functions | Not listed | Yes |
| Replication | Not listed | Async, sync, logical |
| Write-ahead logging | Not listed | Yes |
| Column and row security | Not listed | Yes |
| Full-text search | Not listed | Yes |
If a feature you depend on reads 'Not listed', confirm it in that project's documentation before you build on it.
Analysts and data scientists: the DuckDB case
If your work looks like loading big files, joining a few tables and running aggregations to answer a question, this is the one built for you. Its own page says it targets analytical query workloads, and because it lives inside your Python or R session there's no separate service to stand up, secure or keep running.
- You're crunching exports, logs or CSV files on a laptop and want SQL rather than hand-written loops.
- You'd like the database to travel with a notebook or script, with nothing for a colleague to install first.
- A small footprint matters to you; the project says it pulls in nothing external when it's built or when it runs.
- You still want results you can trust after a crash or an interrupted write.
If you're also weighing SQLite, there's a closer look at DuckDB against SQLite.
App builders and teams: the PostgreSQL case
If you're building something that many people or services will read and write at the same time, PostgreSQL is the natural home. Its feature list is aimed at exactly that: copies of your data on other machines, rules about who can see which rows and columns, and room to bolt on new kinds of data and logic of your own.
- You're building a web app or API whose records need to be available all day to many users.
- You want standby copies on other machines, whether kept in step or updated a moment behind.
- Different people should see different slices of the same table without you building separate copies.
- You'd like to search through stored text without bolting on another tool.
- Your data model needs shapes or logic the standard set doesn't cover.
If you're comparing server databases more widely, there's a separate guide to the MySQL decision that covers that pairing.
Your own types and functions
PostgreSQL lets you create new data types and write functions of your own. In plain terms, if your records don't fit neatly into numbers, text and dates, you can teach the database a new shape rather than squeezing your data into the wrong one.
That matters most for long-lived applications, where the data model grows over years. If your project is a one-off analysis of a few exports, you're unlikely to need it. If it's the backbone of a product, it's worth checking early whether the kinds of data you'll store are covered, and how much custom logic you'd want to keep inside the database itself.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
What both of them give you
The overlap is bigger than the headline suggests. Both are relational at heart and both use SQL, so the skills you build on one carry across to the other. Both talk about ACID transactions, which means a half-finished write shouldn't leave your data in a broken state. And both are open source projects you can read and run yourself.
That shared ground is why they often sit side by side in the same team rather than competing. A server database can hold the live records an app depends on, while an embedded engine handles one-off analysis on exported data without putting load on the live system. You don't have to pick one forever.
Five checks before you commit
- Write down who needs access. If it's one person or one process, embedded is in play. If it's many users at once, start with the server.
- Look at your heaviest query. Large scans and aggregations lean analytical; many small reads and writes lean towards an application database.
- If you'll want to reach the database from another machine, check what Quack covers first.
- List the features you can't live without and confirm each one in the documentation of the option you favour.
- Run a small proof of concept on a real slice of your data, not a toy sample, and time the queries that matter to you.
A day spent on that last step will tell you more than any spec sheet. Use your own data, your own queries and the machine you'll run it on.
Signs you've picked the wrong one
It's not always obvious at the start, so here are the warning lights that tend to show up a few weeks in.
- You're writing glue code so several people can reach a database that lives inside one person's notebook. That's a server-shaped job.
- Your server is busy with long reporting queries that slow the app for everyone else. Exporting that work to an embedded engine may help.
- You keep copying files around by hand so colleagues can run the same analysis. A shared, always-on database would save the shuffle.
- You've set up and secured a whole server just to answer questions about a few spreadsheets. An in-process engine would have been lighter.
Frequently asked questions
Can DuckDB back my web app?
It wasn't designed as a shared server, so treat that as an experiment and read up on the Quack protocol first.
Can DuckDB stand in for a shared data warehouse?
It targets analytical work and runs inside one program by default, so check its documentation on scale and shared access before planning it as a team-wide store.
Do I need admin rights to try an embedded database?
Usually not, since there's no service to install, but your workplace's software rules still apply.
Can I query PostgreSQL tables from DuckDB?
Check its documentation for what it can connect to, and don't assume a direct link until you've confirmed it there.
Are both of them open source?
Both projects call themselves open source. If your organisation needs the exact terms before you adopt one, read each project's licence page.
Which should a beginner learn first?
Learn SQL on whichever matches your first real project; the language skills carry across both.
