Where your data actually lives

"The cloud" is somebody's computer; this page says whose, and in what shape. No badges, no diagrams with padlocks — the physical facts, each one checkable, and the reason the last one matters most.

Your tables are actual tables

When you create a table in Tabla, Postgres runs CREATE TABLE. Your table is a real table in a real database — its own columns, its own rows — not rows filed into some giant shared everything-table with your name on a column. Most no-code tools do the latter; it's why their exports come out funny and their performance sags as you grow.

Real tables are why sorting and filtering are real SQL, why a 50,000-row table opens fast, and why the export is honest: CSV files that mean what they say, because the structure they came from was never a trick. The product doesn't hide the fact even where it's scary — the dialog that deletes a table warns that it drops "the real table", because there is one to drop.

The three places

Records: Postgres on Hetzner — Nuremberg, Germany. A place, not a region code, and not a dropdown you could have gotten wrong. That's where every record you type ends up.

Files: Cloudflare R2. Attachments and profile photos live in S3-compatible object storage, and the "compatible" is doing real work: Tabla talks to storage in the plain S3 language, with nothing provider-specific in the path. Your files aren't reshaped, renamed or wrapped — they keep the names you gave them all the way into the export zip.

Backups: nightly, off-site, kept 30 days. Every night at three in the morning, box time, the whole database is dumped, compressed, and shipped to off-site storage — deliberately separate from the primary host, because a backup that lives next to the thing it protects isn't one. Each night's copy is kept for 30 days, then deleted. This is disaster recovery for the service, not a feature you restore from yourself; the recovery tools in your hands are the export, any day, and the trash for the records you delete yourself.

The 30-day roll-over cuts both ways, honestly: deleted data survives in off-site backups for up to 30 days after it leaves the product, and then it's gone from there too. Leaving Tabla walks through what that means when you're deleting on purpose.

No password database to breach

Signing in works by magic link: you prove you control your inbox, every time. Tabla stores no passwords — not hashed, not encrypted, not at all — which means there is no password table to steal, leak, or crack, and no reused password of yours for anyone to try here. What is stored is hashes: sessions, API keys and invitation links all keep only a hash of their secret, so a copy of the database yields none of them. Sessions expire after 30 days; traffic to tabladb.com runs over HTTPS.

What we do with it: nothing

The /your-data page carries the policy in full, and it's short: we don't read your records, we don't train anything on them, and we don't sell them or access to them. The one exception is when you ask — a support request about a specific thing may need us to look at that specific thing, and we tell you when we do.

You'll notice what this page doesn't have: compliance badges. It's an ownership page, not a security theater page — the claims here are the ones we can show you, not the ones a certificate implies.

The exit is the proof

Every claim above could be marketing. The one that keeps us honest is the last one: the whole database — tables as CSV, files as files, structure as a manifest — leaves in one zip, in one click, any day, on every plan including the free one. Nothing in that zip needs Tabla to open it. A service that hands you everything on demand has no room to get weird about where it keeps it.

The long version of that promise is /your-data; the mechanics are export your database.