Postgres · Storage · One console

The data platform your products run on.

Create PostgreSQL databases, schemas and tables, run SQL, and manage file storage for every project, all from one secure, multi-tenant console.

  • Standard PostgreSQL
  • S3-compatible storage
  • Tenant isolation built in
console.zippabase / acme-prod / database
public.customers
ColumnsDataDefinition
NameTypeDefaultConstraints
idint8—PK
emailtext—UNIQUE
org_iduuid—orgs.id
created_attimestamptznow()NOT NULL
select email, created_at from customers
where org_id = '8f2c…' order by created_at desc;
✓ SELECT · 3 rows · 4 ms
Built on open standardsPostgreSQLSQLS3 APIREST / JSONTLS everywhere

Platform

Everything a product team needs from its data layer

Databases, SQL and storage live together under one project, with one permission model and one API.

Database management

Run multiple PostgreSQL databases per project and organize them into schemas. Design tables visually.

  • Tables, views, functions, indexes
  • Primary keys, unique, foreign keys
  • Generated DDL for every object

SQL editor

Write standard PostgreSQL. Objects you create with SQL show up straight away in the visual explorer.

  • Multi-statement scripts
  • Run all or a selection
  • Per-statement results and errors

File storage

S3-compatible buckets with folders, drag-and-drop uploads and a storage allocation for each project.

  • Public and private buckets
  • Nested folders
  • Quota enforcement and usage

Multi-tenant by design

Every resource belongs to an organization. Isolation is built into the data model, not added later.

  • Organization → project → resources
  • Per-project databases
  • Tenant-scoped access checks

API-first

The console uses the same versioned REST API your applications and automation will use.

  • One documented contract
  • Consistent error codes
  • Token-based sessions

Regional placement

Choose where each project's data lives so you can meet latency and data-residency requirements.

  • Region per project
  • Mumbai, Singapore, Frankfurt, N. Virginia
  • Set at creation

Visual and SQL, in sync

Design visually. Script it in SQL. Both show the same database.

Analysts can click, engineers can type, and both see the same database. Scripts run statement by statement, with clear results and PostgreSQL-style errors, and the explorer updates as soon as the script finishes.

  • CREATE / ALTER / DROP for schemas, tables, views, functions and indexes
  • Foreign keys, defaults and constraints, checked on every write
  • Destructive operations need CASCADE, just like PostgreSQL
SQL EditorRun ⌘↵
-- billing schema
create schema billing;
create table billing.invoices (
  id bigserial primary key,
  customer_id bigint not null references customers(id),
  amount numeric(12,2) not null,
  issued_at timestamptz default now()
);
create index invoices_customer_idx on billing.invoices (customer_id);
CREATE SCHEMA · billing
CREATE TABLE · billing.invoices (4 columns)
CREATE INDEX · invoices_customer_idx

Security & governance

Designed for teams that answer to auditors

Isolation, least privilege and guardrails are part of the architecture from day one.

Google sign-in

No passwords to leak or guess. Sign-in uses Google with PKCE, and each sign-in is bound to the browser that started it.

Tenant isolation

Every request is authorized against organization membership. Each project gets its own database.

Least-privilege execution

User SQL runs under a restricted per-project role, never a superuser.

Guardrails

Quotas, validated identifiers, typed confirmations for destructive actions, and cascades that are spelled out before you confirm.

Every tenant boundary is enforced on the server. The console has no privileged back door.

Read the FAQ →

How it works

From sign-up to a production schema in minutes

  1. 01

    Create a project

    Pick a name, a region and a storage allocation. A Postgres database and a public schema are ready immediately.

  2. 02

    Model your data

    Design tables in the visual editor or paste a SQL script. Both stay in sync.

  3. 03

    Store your files

    Create buckets and folders, upload assets, and keep an eye on usage against your allocation.

  4. 04

    Connect your apps

    Point your services at the project's API and connection string, and build on it.

Roadmap

Built in the open, shipped in phases

Here's what is available today and what is coming next.

Available now
  • Google sign-in
  • Projects, databases and schemas
  • Visual table designer
  • SQL editor
  • Buckets, folders and quotas
Next
  • Dedicated PostgreSQL clusters
  • S3-compatible object storage
  • Connection strings and API keys
  • Joins, aggregates, full SQL
Later
  • Team roles and invitations
  • AI access via MCP
  • Usage-based plans
  • Auto-generated REST APIs and row-level security

FAQ

Questions, answered

Is Zippabase PostgreSQL?

Yes. Every project database is standard PostgreSQL, so your existing tools, drivers and SQL skills work unchanged.

Can I mix the visual editor and SQL?

Yes. The explorer and the SQL editor operate on the same database. A table created with SQL appears in the explorer, and a table built in the designer shows its generated DDL.

How is my data isolated from other customers?

Resources belong to an organization, and every request is checked against your membership. Each project runs in its own database.

Where is my data stored?

You choose a region for each project when you create it. Database and file storage for that project stay in the region you picked.

What does the current preview include?

The full console experience: projects, databases, schemas, tables, SQL and storage. Dedicated database servers and object storage are being rolled out next; see the roadmap.

Give your next product a solid foundation.

Create your first project and have a working schema before your coffee cools.