The fastest way I spot a version mismatch is when a deployment that was smooth in staging suddenly fails in production. One small difference in a database version can change a default setting, a system catalog view, or a replication behavior. I have seen migrations pass locally and stall on a CI runner because the server was older than expected. That is why I treat version checks as a basic safety step, not a trivia question. You should know exactly which PostgreSQL version you are running, how to verify it from different angles, and how to explain the results to your team.
In the next sections I will walk through the practical ways I check my PostgreSQL version in real projects: from the command line, from SQL, from client tools, from inside containers, and across fleets. I will also show common mistakes I have made (and how to avoid them), plus the small differences between server, client, and library versions that bite in production. You will get runnable commands, short explanations, and guidance on which method to use when.
Why I Check Version First (And Why You Should Too)
When something breaks, I want the least surprising root cause. Version is often the simplest explanation. I have run into these real-world problems:
- A migration uses GENERATED ALWAYS AS IDENTITY, but the database is still on PostgreSQL 9.6, where the syntax is not available.
- An extension like pgstatstatements is installed, but a new column only exists in PostgreSQL 14+, so a monitoring query fails.
- A replica gets stuck because walkeepsize replaced walkeepsegments in newer releases, and the config is now wrong.
You can avoid most of this by checking the server version up front. I do not mean assuming it is the same as dev. I mean verifying it at the start of any debugging, migration, or environment review. It is a 5 to 10 second check that saves hours.
Understanding PostgreSQL Versioning (So You Read It Correctly)
Before running commands, I make sure everyone is talking about the same thing. PostgreSQL uses a major.minor versioning scheme. The major version is the first number, like 14 or 16. The minor version is the patch level, like 14.11 or 16.2. Major versions add or change features and sometimes defaults. Minor versions are bug fixes and security patches.
Why this matters in practice:
- If I am choosing a feature, I care about the major version. For example, generated columns and logical replication enhancements arrived in specific majors.
- If I am debugging a subtle bug or a security issue, I care about the minor version. Those fixes land in minor updates, and they can be important even if the major stays the same.
- Some managed services advertise only the major version in the UI, but they apply minor patches in the background. That can be good for security, but it can also shift behavior slightly between environments.
When I compare versions, I decide whether I need exact matches (for reproducibility) or just a minimum major version (for feature availability). That choice changes which command I use and how strict my CI guardrails are.
The Fastest CLI Check: postgres -V and psql –version
When I am on a host where PostgreSQL is installed, I start with the binaries. This tells me which client or server binaries are present on the machine, not necessarily what the remote database is running.
postgres -V
Typical output:
postgres (PostgreSQL) 16.2
That is the server binary version installed on the machine. If I am dealing with a local server, it is often the same as the running server, but not always. On build servers, I might have 16.x installed while the running service is a container with 15.x.
Then I check the psql client:
psql --version
Typical output:
psql (PostgreSQL) 16.2
This is the client, not the server. I use it as a quick hint, but I never stop there. If you use a shell script or an automation job, verifying psql is installed and recent helps avoid protocol feature mismatches. But the server version is the real goal.
OS package checks (useful when you cannot connect)
Sometimes I cannot connect to the server, so I check the package manager to see what is installed on the host. This does not guarantee the running server version, but it gives me a clue.
Examples:
apt list --installed | rg postgresql
dnf list installed | rg postgresql
brew list --versions | rg postgresql
If I see multiple major versions installed, I know I need to be precise about which cluster I am actually connecting to. On Linux hosts that run multiple clusters, each data directory can be on a different major version.
The Most Reliable Answer: SELECT version()
If I can connect to the database, I ask the server directly. This is my go-to for accuracy.
psql ‘postgres://app_reader:[email protected]:5432/app‘ -c ‘SELECT version();‘
Typical output:
PostgreSQL 16.1 (Ubuntu 16.1-1.pgdg22.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
This gives me the server version, build, compiler, and architecture. I rely on this when I need to explain differences across environments. It also tells me the distro packaging, which matters for security patch policies and default config values.
If you are scripting, I use SHOW server_version because it is cleaner to parse:
psql ‘postgres://appreader:[email protected]:5432/app‘ -t -A -c ‘SHOW serverversion;‘
Output:
16.1
-t -A removes headers and extra formatting. That lets me stuff the version into a variable or compare it in a script.
When I prefer serverversionnum
When I need strict comparisons, I use serverversionnum, which is an integer for easy numeric checks.
psql ‘postgres://appreader:[email protected]:5432/app‘ -t -A -c ‘SHOW serverversion_num;‘
Output:
160001
That string is great for comparisons in CI and migrations. For example, I might block a migration that requires 14+.
Interpreting serverversionnum correctly
I have seen people misread serverversionnum. The format is major 10000 + minor 100 + patch. So PostgreSQL 16.1 becomes 160001. PostgreSQL 15.10 becomes 151000. That is why integer comparisons work: 160001 is greater than 150999. I still keep a small helper in scripts so future me does not have to remember the math.
Example in bash:
versionnum=$(psql "$DATABASEURL" -t -A -c ‘SHOW serverversionnum;‘)
if [ "$version_num" -lt 140000 ]; then
echo ‘Requires PostgreSQL 14+‘ >&2
exit 1
fi
Inside psql: Quick Checks I Use Daily
If I already have an interactive shell, these are my favorites:
SELECT version();
SHOW server_version;
SHOW serverversionnum;
The difference: version() is human-friendly; serverversion is readable and parseable; serverversion_num is comparison-friendly. I do not use version() in scripts unless I am logging details for debugging.
psql meta-commands that help
psql has a few meta-commands that are useful when I am already connected. They are not version checks directly, but they help me validate that I am on the expected server.
- \conninfo shows the current connection target and user.
- \l shows databases on the server, which helps confirm I am not on a dev clone.
- \dx shows installed extensions and their versions.
When I debug, I often run \conninfo and SHOW server_version back to back. It is a quick confirmation that I am on the server I think I am.
A quick helper function (optional)
In a team environment, I will sometimes create a helper function in a shared admin schema so other engineers can check without remembering the query.
CREATE OR REPLACE FUNCTION admin.pg_version()
RETURNS text
LANGUAGE sql
AS $$
SELECT currentsetting(‘serverversion‘);
$$;
Then anyone can run:
SELECT admin.pg_version();
That keeps a consistent output and avoids long version() strings in logs.
GUI and Client Tools (When You Are Not Living in the Terminal)
Not everyone spends their day in a shell. When I am working with teammates who prefer a GUI, I point them to a SQL console and the same SHOW server_version query. The tool does not matter as long as the query runs on the server.
Common places I run the query:
- pgAdmin Query Tool
- DBeaver SQL Editor
- DataGrip Console
- TablePlus SQL Query
In all of these, I paste:
SHOW server_version;
If a tool shows a version in its UI, I still run the query. Some tools display the client library version instead of the server version, and that can mislead people who are not thinking about the difference.
Docker, Kubernetes, and Hosted Databases
Modern setups hide the database behind containers or managed services. I still check the server version in a consistent way, but the entry point changes.
Docker (local or CI)
If your database is running in a container, you can exec into it and run psql locally, or use your host psql to connect over the mapped port.
docker exec -it pg-dev psql -U postgres -c ‘SHOW server_version;‘
If the container does not include psql (some minimal images do not), I connect from the host:
psql ‘postgres://postgres:secret@localhost:5432/postgres‘ -c ‘SHOW server_version;‘
Kubernetes
In Kubernetes, I usually port-forward and then use my local psql:
kubectl -n data port-forward svc/postgres-primary 5432:5432
psql ‘postgres://appreader:secret@localhost:5432/app‘ -c ‘SHOW serverversion;‘
If I am on a bastion or jump host, I might exec into the pod:
kubectl -n data exec -it statefulset/postgres-0 -- psql -U postgres -c ‘SHOW server_version;‘
Managed services
On managed providers, I still run the same SQL query. The only difference is how I get credentials. I never trust the console label alone because providers sometimes apply minor versions in the background and update a label later. The server should tell you the truth.
Containers plus multiple clusters
A common trap is a container image that bundles multiple versions or multiple data directories. You might be executing psql inside the container but hitting a different instance through a service. I always verify the connection host and port (\conninfo in psql) and then check server_version. It sounds redundant, but it saves me from chasing the wrong database.
Application-Level Checks (Python, Node.js, Go)
Sometimes I need to check a version inside the app itself, especially when a feature is optional. I keep it simple and cache the value so it does not run on every request.
Python (psycopg)
import psycopg
conn = psycopg.connect(‘postgresql://app_reader:[email protected]:5432/app‘)
with conn.cursor() as cur:
cur.execute(‘SHOW server_version;‘)
version = cur.fetchone()[0]
print(version) # e.g., ‘16.1‘
If I need a numeric comparison:
cur.execute(‘SHOW serverversionnum;‘)
version_num = int(cur.fetchone()[0])
if version_num < 140000:
raise RuntimeError(‘Requires PostgreSQL 14+‘)
Node.js (pg)
import pg from ‘pg‘;
const pool = new pg.Pool({
connectionString: ‘postgres://app_reader:[email protected]:5432/app‘
});
const result = await pool.query(‘SHOW server_version;‘);
const version = result.rows[0].server_version;
console.log(version); // ‘16.1‘
Go (pgx)
package main
import (
"context"
"fmt"
"github.com/jackc/pgx/v5"
)
func main() {
conn, err := pgx.Connect(context.Background(), "postgres://app_reader:[email protected]:5432/app")
if err != nil {
panic(err)
}
defer conn.Close(context.Background())
var version string
err = conn.QueryRow(context.Background(), "SHOW server_version;").Scan(&version)
if err != nil {
panic(err)
}
fmt.Println(version)
}
Java and .NET quick checks
If I am in a Java or .NET service, I do the same thing: run SHOW server_version once on startup and store it. The exact driver call changes, but the SQL does not. I keep the query in a single place so all environments report it consistently.
Server vs Client vs Library Versions: I Do Not Confuse Them
A surprisingly common mistake is mixing up three different version numbers:
- Server version: what PostgreSQL is running on the database host.
- Client version: the psql (or driver) you use to connect.
- Library version: the libpq or driver package version.
Why this matters: a newer client can talk to an older server, but not always with feature parity. For example, a driver might expose pipeline mode or newer authentication methods only when the server supports them. I check server version for compatibility, client version for tool behavior, and library version for driver features.
To see the client libpq version from psql, I run:
pg_config --version
If I am in a language runtime, I check the library package version in my dependency files (package.json, pyproject.toml, go.mod). I treat these as independent pieces.
Traditional vs Modern Ways I Check Version
Here is how I compare the old-school methods with what I prefer in 2026 workflows.
Traditional
—
SELECT version() manually
postgres -V on server
manual notes in docs
logging into each host
I still use the traditional commands for quick diagnosis, but I trust automated checks more because they do not forget.
Fleet-Wide Checks and Audits
When I manage multiple environments, I collect versions across the fleet. I use a simple script with a list of connection strings in a secure vault. Then I pipe the output to a small report. Example shell approach:
#!/usr/bin/env bash
set -euo pipefail
while read -r name url; do
version=$(psql "$url" -t -A -c ‘SHOW server_version;‘)
printf ‘%s\t%s\n‘ "$name" "$version"
done < connections.txt
In production, I never store raw credentials in connections.txt. I pull them from a secret manager or an encrypted file. The pattern stays the same: query SHOW server_version, collect results, and compare.
If you are using infrastructure-as-code, I prefer to annotate the database resource with the version too, then validate it at runtime. That gives you both a declared version and a real one. If they diverge, something drifted.
A more robust inventory pattern
When the fleet grows, I stop using a flat text file and move to a small inventory format (YAML or JSON) with names, roles, and connection info. That makes it easier to filter on prod-only, or check only replicas. I also include a label for the expected major version and alert if the actual version does not match.
Common Mistakes I See (And How I Avoid Them)
Here are the mistakes I have made or seen and how I prevent them now.
1) Checking only the client version
I see engineers run psql –version and assume that is the server. It is not. I always run a SHOW server_version query against the database itself.
2) Trusting labels in managed dashboards
Dashboards often show a major version but can lag on minor patch levels. I still run a SQL query, especially before upgrades or when debugging behavior changes.
3) Ignoring minor versions
Minor releases include security fixes and bug fixes. If an issue appears random, I double-check the minor version first. I have seen fixes land in 15.4+ that eliminated a lock contention bug that appeared under heavy load.
4) Assuming all environments match
Staging is often upgraded before production. I include a version check in deployment logs so we can quickly see if staging and production are aligned.
5) Parsing version() output in scripts
version() output is verbose and can change format slightly. I use SHOW server_version for scripts and comparisons.
6) Forgetting that replicas can differ
In mixed clusters, a replica might be on a slightly different patch level right after a rolling upgrade. I verify the version on the specific connection target, not just the primary.
When to Use Which Method
I recommend matching the method to the situation:
- Quick local check: postgres -V and psql –version are fine.
- Accurate server check: SHOW server_version is my default.
- Automated validation: SHOW serverversionnum in CI or migrations.
- Troubleshooting build or packaging: version() for full details.
- Multi-environment audits: a script that queries SHOW server_version across targets.
If you are unsure, use the SQL query. It is the most trustworthy method because it comes from the server itself.
Performance and Overhead
Version checks are cheap. In my experience, a single SHOW server_version query completes in typically 10 to 15 ms on local networks and 30 to 80 ms on cross-region connections. That is fast enough for startup checks but too slow for per-request checks in a high-traffic API. My rule is: check once on boot, cache the value, and log it. For long-running services, I only re-check if a connection error suggests failover to a different server.
If you are concerned about startup time, you can run the check asynchronously and record it when ready. The key is to avoid hitting the database on every request just to learn its version.
Edge Cases That Matter More Than You Think
A few tricky situations I have learned to account for:
- Read replicas: A replica might lag a major upgrade if the topology was changed. I check the version on the specific server role I am using.
- Logical replication: Some features require the publisher and subscriber to be on compatible versions. I check both ends before enabling replication slots.
- Extensions: An extension might require a specific server version. I check the server first, then confirm extension versions with \dx in psql.
- Mixed containers: In dev, different engineers may have different image tags. I check the version inside the container, not the tag name.
- Connection poolers: If a pooler routes me to multiple backends, I run SHOW server_version once per backend when I need absolute certainty.
Version Checks During Upgrades and Migrations
When I do an upgrade, I treat version checks as gates. It is not enough to upgrade the primary; I confirm that every endpoint my app uses is on the expected version.
My typical upgrade workflow:
1) Pre-upgrade audit: collect current versions across the fleet.
2) Upgrade primary: verify SHOW server_version on the primary.
3) Upgrade replicas: verify each replica, especially if reads are served from them.
4) Validate extensions: confirm extension versions match the new server.
5) Update tooling: bump client libraries if needed.
During a migration, I add a guard clause in the migration code itself. If the server is below the required version, I stop early with a clear error. That makes the failure obvious instead of letting a more obscure error pop later.
Practical Guidance for Teams and CI
If you run a team or a CI pipeline, I recommend making version checks part of your routine workflow. Here is a pattern I use:
1) Pre-migration check: abort if server version is below the required threshold.
2) Post-deploy log: print the server version in deployment logs.
3) Health endpoint: expose the server version in a protected admin endpoint.
4) Drift detection: alert if any environment runs an unapproved major version.
This is not busywork. It is a small guardrail that prevents bigger failures.
Example CI guardrail (pseudo)
In CI I keep it minimal: connect, fetch serverversionnum, compare, exit.
versionnum=$(psql "$DATABASEURL" -t -A -c ‘SHOW serverversionnum;‘)
if [ "$version_num" -lt 150000 ]; then
echo ‘CI requires PostgreSQL 15+‘ >&2
exit 1
fi
Example health endpoint idea
If I control the app, I add a protected endpoint that returns the server version and the database host. It is only for operators, but it is a fast way to confirm where the app is connected after a deployment.
I Also Check the Runtime Driver Version
Sometimes the bug is not the server; it is the client driver. If I see odd errors around authentication or TLS, I confirm the driver version and compare it to the server major version. Many 2026 drivers have better defaults for TLS and authentication, but older ones may fail when servers are upgraded to stronger auth methods.
When I upgrade PostgreSQL to a new major version, I also upgrade the driver to a recent release. That reduces protocol mismatches and gives me access to newer features like extended query handling or pipeline mode.
Alternative Ways to Verify (When SQL Is Not Available)
Sometimes I cannot run SQL at all because credentials are missing or the connection is blocked. In those cases, I fall back to other clues:
- Check service logs for a startup line that includes the version.
- Inspect the data directory with tooling that identifies the major version (for example, pg_controldata on the host).
- Check the container image tag, but only as a hint, not as proof.
- Ask the infrastructure team for the declared version in their IaC config.
These are not substitutes for SHOW server_version, but they can unblock me when I am investigating and waiting for access.
AI-Assisted Workflows (How I Speed Up Version Checks)
When I am handling many environments, I sometimes use an AI helper to generate a quick inventory script or to analyze the output for anomalies. I still run the check myself, but the assistant can help me spot an outlier or generate a small report. The key is that the source of truth remains the database query. AI helps with the glue, not the facts.
Checking the Running Service on Linux and Windows
On servers I manage directly, I like to confirm the running service too. This does not replace SHOW server_version, but it helps me catch cases where the binary is upgraded and the service was never restarted.
On Linux with systemd, I start with the service status:
systemctl status postgresql
Then I look at the command line used to launch the server. The path to postgres often includes the major version, which is a good sanity check. If I see the wrong binary path, I know the service might be pointing at a different install than I expect.
On Windows, I check the service list and then confirm the binary version:
Get-Service -Name postgres
& ‘C:\Program Files\PostgreSQL\16\bin\postgres.exe‘ --version
If I have access to a Windows server but not a SQL client, that binary check at least tells me what is installed. Again, it is a clue, not proof of the running server. I still want to run SHOW server_version when possible.
Multiple Clusters on the Same Host (How I Avoid Confusion)
It is common to have more than one cluster on a host, especially in dev or build servers. That is where mistakes happen. I keep three rules:
1) Always note the data directory. The data directory is tied to a specific major version.
2) Always note the port. Each cluster should use a unique port.
3) Always verify the connection target with \conninfo.
If I am not sure which data directory a service uses, I look at the service definition. On Debian-based systems, I might see multiple clusters listed and their ports. On custom setups, I check the service unit or launch script.
When in doubt, I run SHOW datadirectory and SHOW configfile after connecting. Those two settings tell me exactly which cluster I am on and which configuration is active.
Feature Detection Beyond Version Numbers
Sometimes I need more than a version number. If I am using an extension or a feature that is optional, I will check directly for it. This is useful when I am in environments where the version is high enough but a feature is still disabled.
Examples I use:
- Does the extension exist?
SELECT 1 FROM pgextension WHERE extname = ‘pgstat_statements‘;
- Is the feature toggle enabled?
SHOW wal_level;
- Does a column exist in a system view?
SELECT 1 FROM information_schema.columns
WHERE tableschema = ‘pgcatalog‘
AND tablename = ‘pgstat_statements‘
AND column_name = ‘plans‘;
This approach works even when I cannot upgrade immediately. I can branch logic based on the actual feature availability rather than guessing from the version alone.
Version Checks in Migration Tools
If you use migration tools like Flyway, Liquibase, Alembic, or Django migrations, you can embed a version guard at the start of the migration. I do this whenever a migration depends on a feature introduced in a specific major version.
The pattern is simple: run SHOW serverversionnum and compare. If it is too low, fail with a message that explains the minimum required version. This turns a confusing SQL syntax error into a clear operational signal.
I also add a note in the migration docs so the next person knows why the guard exists. It makes upgrades smoother because the requirement is visible both in code and in human-readable notes.
Observability: Logging and Metrics
Version checks are not just for debugging. I log them during deploys and record them in monitoring. Two practices that help me:
- Include the server version in application startup logs. That makes it trivial to confirm what version the app saw at boot.
- Emit a metric or label (for example, db_version=16.1) in a protected admin dashboard or internal metrics stream.
I avoid putting the version in public endpoints, but I am happy to surface it internally. When I compare incidents between environments, that version label is one of the first things I check.
Troubleshooting Mismatches (A Practical Scenario)
Here is a real pattern I have seen:
- Dev runs PostgreSQL 16.2 in Docker.
- Staging runs PostgreSQL 15.5 on a managed service.
- Production runs PostgreSQL 15.2 on a legacy VM.
A migration introduces generated columns and passes in dev, passes in staging, and fails in production. The team assumes a permissions issue, but the real issue is a version gap in production. In this situation I do three things immediately:
1) Run SHOW server_version in all three environments and compare.
2) Identify the minimum required version for the feature in the migration.
3) Either update production or gate the migration with a clear error message.
This is why I push for version checks as part of deployment logs. It makes the mismatch visible before the migration even runs.
Security and Compliance Considerations
I treat minor versions as a security requirement. When a vulnerability is disclosed, the fix usually arrives in a minor release. If my compliance policy requires patches within a certain window, I need to know which minor versions are running. That is another reason I automate version collection and keep it in a report.
If you are audited, the ability to show a fleet-wide version inventory is a strong signal that you are managing patch levels intentionally. A simple report generated from SHOW server_version can satisfy many audit questions.
When Not to Overthink Version Checks
There are times when a basic check is enough. If I am on my laptop running a single local instance, postgres -V and SHOW server_version probably align. I still run the SQL once just to be sure, but I do not build a whole workflow for it.
The key is to match effort to risk. For local dev, I am relaxed. For production, I am strict.
A Step-by-Step Walkthrough (How I Do It Under Pressure)
When an incident is active, I do not want to think. I follow a short flow that gets me the version quickly, even if I am not sure where the database lives.
1) Identify the connection string the app uses. I start with environment variables or secrets.
2) Connect from my machine using psql and run SHOW server_version.
3) Run \conninfo to confirm the host and port.
4) If I cannot connect, I check the service logs on the host for a startup banner.
5) I write the version in the incident notes so everyone sees it.
This flow might sound basic, but it avoids a common mistake: checking the wrong server. In incidents, people often connect to a staging database out of habit. That is why \conninfo is part of my muscle memory.
Signs You Are Looking at the Wrong Version
Sometimes the version mismatch is not obvious. I have learned to recognize a few early signals:
- A SQL feature fails with a syntax error that should not happen on your expected version.
- An extension query fails because a column is missing.
- A config parameter from your docs is rejected as unknown.
- A tool that usually works starts warning about protocol differences.
When I see one of these, I run SHOW server_version before I do anything else. It is the fastest way to eliminate a whole class of problems.
How I Communicate Version Info to the Team
The version is not just for me. I need other people to see it quickly. My standard message format looks like this:
- Server version: 16.1
- Client version: psql 16.2
- Host: db.prod.internal:5432
- Evidence: SHOW server_version on January 9, 2026
That last line matters. I include the date and method so we can trust the check. If someone sees a different version later, we can tell whether the database was upgraded or whether we checked a different server.
Short FAQ (Questions I Get Every Time)
Does psql –version show the server version?
No. It shows the client version. You need to run SHOW server_version or SELECT version() after you connect.
Do I need superuser privileges to check the version?
No. SHOW server_version is available to regular users. That is one reason I like it.
Why does version() include extra text?
version() is a full build string. It includes packaging and compiler details, which can be useful for debugging. For scripts, I prefer SHOW server_version because it is consistent and easier to parse.
Can a server be patched without changing the major version?
Yes. Minor releases are patches. That is why 15.2 and 15.6 can behave slightly differently even though they are both major version 15. If you care about bug fixes or security, you should track minor versions.
Do I need to restart the server after an upgrade?
Yes, for the running version to change. It is possible to upgrade packages on disk but keep the old version running until a restart. That is why I sometimes check the service status and the server version separately.
A Quick Checklist I Keep Nearby
When I am in a hurry, this is the list I follow:
- Can I connect? If yes, run SHOW server_version.
- If I need numeric comparisons, run SHOW serverversionnum.
- If I am in a container or Kubernetes, connect through port-forward or exec a pod and run the same query.
- If I cannot connect, check the host packages or service logs as a temporary hint.
- Record the result in deploy logs so the team can see it later.
Putting It All Together (My Default Playbook)
If you want one simple playbook, this is the one I use:
1) Run SHOW server_version against the actual database endpoint.
2) Record the value in logs or deployment output.
3) If the version is below a minimum, fail fast with a clear message.
4) If a bug appears, compare versions across environments first.
5) Update clients and drivers when you move major versions.
That is it. It is boring by design, and it saves me from the most common surprises.
Final Thoughts
Knowing your PostgreSQL version is the smallest possible debugging step that unlocks faster root causes and safer migrations. I treat it like checking the hostname or the current branch: it takes seconds, and it saves hours. Whether I am in a container, a managed service, or a local dev box, the query is the same. I want the database to tell me the truth directly. The rest is just plumbing.
