What is a data warehouse? Database vs. warehouse, with a Neon walkthrough

"Data warehouse" gets used for almost any place business data is stored. It actually means something specific, and most small businesses need something else first.

This guide explains the difference between a database and a data warehouse using one business's data, helps you decide what you need, and walks through setting up a real database with Neon.

One business, three places data can live

Imagine a home-services company. Its customer details, jobs, and invoices could live in three kinds of places, each built for a different job.

A spreadsheet

Fine for one person and a few hundred rows. It breaks down when several people edit at once, when apps need to read it, or when nobody knows which copy is current.

A database

A database is built to run your business: store records, and let apps create, read, and update them quickly and safely, many times a second. Your CRM has a database inside it. So does every web app. When someone submits a form and a record appears, a database is doing the work.

The technical name for this kind of work is OLTP (online transaction processing): many small, fast reads and writes.

A data warehouse

A data warehouse is built to analyze your business. It pulls copies of data from many systems (CRM, accounting, ads, scheduling), keeps the history, and is designed to answer big questions across all of it: "Which lead source produced the most profitable jobs over three years?"

The technical name is OLAP (online analytical processing): fewer, much larger queries over lots of data. Well-known warehouses include Snowflake, Google BigQuery, and Databricks.

Side by side

How they fit together

Do you need a data warehouse?

Most small businesses do not, yet. You probably need one when:

• You want reports that combine three or more systems, and doing it in spreadsheets takes hours every week.
• You have years of history and questions that span it.
• Reporting queries are slowing down the apps your team uses.

Before that point, the better investment is usually clean data in your CRM and a proper database for any custom app you build. A warehouse full of messy data just gives you messy reports faster.

Where Neon fits

Neon is a database, not a data warehouse. It is hosted Postgres (one of the most widely used databases) that runs in the cloud with no server to manage. A few features make it well suited to small teams and modern apps:

• Scale to zero. When nobody is using the database, it can pause, so a quiet app costs little.
• Branching. You can create an instant copy of your database to test changes safely, the same way you branch code.
• Instant restore. You can roll the data back to a recent point in time.

Neon joined Databricks in 2025, and its technology now also powers Databricks' own Postgres offering. That is a sign of where things are heading: operational databases and analytics platforms are moving closer together, but they still do different jobs.

Walkthrough: set up a Neon database

This example creates a simple table of website inquiries that a web app could write to.

Step 1: Create an account and a project

Sign up at neon.com and create a project. Choose a region close to where your users (or your web host) are; it makes every request faster. Neon creates a starting database and a root branch named main.

Step 2 and 3: Create a table in the SQL Editor

Open the SQL Editor and run:

CREATE TABLE inquiries (
  id          serial PRIMARY KEY,
  name        text NOT NULL,
  email       text NOT NULL,
  topic       text,
  message     text,
  source_page text,
  created_at  timestamptz NOT NULL DEFAULT now()
);

Then add a test row and read it back:

INSERT INTO inquiries (name, email, topic, source_page)
VALUES ('Test Person', 'test@example.com', 'Automation', '/contact');

SELECT * FROM inquiries ORDER BY created_at DESC;

Step 4: Copy the connection string

Click Connect on your project dashboard. Neon shows a connection string that looks like this (yours will have real values):

postgresql://USER:PASSWORD@HOST/DATABASE?sslmode=require

That string includes a password. Treat it like one.

Step 5: Store it as a secret

In your hosting provider, add it as an environment variable named DATABASE_URL. On Vercel that is Settings → Environment Variables, followed by a redeploy. Your app's code reads DATABASE_URL and never contains the value itself. Vercel can also add Neon from its Marketplace and set the variable for you.

Step 6: Branch before you change anything

Before changing a table (adding a column, renaming one), create a branch of the database in Neon's console. It is an instant copy of your data. Point a preview version of your app at the branch, test the change, and only then apply it to main. Neon can also create a database branch for each Vercel preview deployment automatically.

Getting data out for reporting

Once your app is writing to Neon, you can report on it without a warehouse:

• Run queries in the SQL Editor for quick answers.
• Connect a dashboard tool that supports Postgres.
• Export to a spreadsheet on a schedule for people who live in spreadsheets.

When you need to combine it with CRM, accounting, and ad data over years, that is the point to add a warehouse downstream.

Common questions

Is my CRM a database?

It contains one, managed for you. You usually work with it through the CRM's screens and integrations rather than directly.

Neon or Supabase?

Both are hosted Postgres. Neon focuses on the database itself, with branching and scale-to-zero. Supabase bundles a database with sign-in, file storage, and other app features. Many AI app builders connect to Supabase by default.

Can a database be too small for a business?

Rarely, at small-business scale. Postgres comfortably handles far more records than most small companies will ever create.