The Excel User's Guide to Databases: Databases and APIs

What's the point of an API if you have a database?

databases

Last updated: July 4, 2025

If you’ve gotten this far, you probably know (a) what a database is and (b) what an API is. A question that has always bothered me is why do we need both? Allow me to further develop the question.

Imagine you’re a software engineer at Twitter (yikes). The data for tweets is stored in a database that probably looks something like this:

Loading image...

The code that builds the Twitter homepage needs to query this database, so you can show the latest tweets, what’s in them, who wrote them, how many likes they have, and such. A basic query to get that information might look like this:

    SELECT
      tweets.tweet_text,
      tweets.sent_at,
      authors.author_name
    FROM tweets
    JOIN authors ON tweets.author_id = authors.id

You’ve also got an API (well many, but this is one) that sits in front of that database. The API was built by some other software engineer, and what it does is runs the exact query above, retrieves the information from the database, and returns it to the requestor. The API request looks something like this:

    GET https://api.twitter.com/tweets

This is standard practice in every engineering organization I’ve ever seen. Database. API in front of database. Query API in application, instead of querying database.

But why don’t you just write that query in your frontend code? Why do you have to go through the trouble of creating all of these different API endpoints to sit in front of your database? Why not just query it directly from your app?

There are basically two answers:

There are a lot of good reasons to separate your database from direct queries
There are many, many other types of APIs other than single query ones

Let us dive in.

Terms Mentioned

Frontend

Server

Backend

API

Analytics

Endpoint

Authentication

Machine Learning

Database

Query

Companies Mentioned

Segment

$TWLO

Stripe

$PRIVATE

Separation of database and API

The lens to look at this through is more about fundamental separation between your database and things that use your database. It’s almost like, why is there a front of the house in restaurants? Why don’t you just go and pick up your food from the counter yourself?

Protecting your backend from strangers

The data in your database is proprietary; you don’t want just anyone to be able to query it. That’s why apps have authentication, so I can’t see what’s in your Gmail inbox, and vice versa. If you issue queries directly against your database, you’d need to use the database for authentication. But when you build an API in front of it, you can implement your own, custom authentication logic.

To translate that to a bit more English, let’s take a look at a hypothetical Gmail endpoint that gives you the 50 most recent emails for a particular email address:

    GET https://api.google.com/mail/messages
    {
      username: “gagejustins”
    }

If you knew this URL, what’s stopping you from making this API request yourself, passing whoever’s email address you want, and getting access to their private data?

The answer is authentication: for every API request, you need to prove that you deserve access to the data you’re asking for. When you successfully log into your Gmail account, a few API requests are made that tell Google’s systems that you’re you, and you’re logged in: accordingly, any subsequent requests from your browser – well, at least for the next hour or so – are coming from you.

With APIs, you can decide how you want your users to authenticate. You can make things more or less secure, revoke access after a short period of time, anything you want. But if each individual copy of your application running in a browser were to query the database directly, then the database would need to be figuring out who deserves access to what data itself. And databases aren’t built for that!

Loading image...

So in short, having an API sit between your application and your database makes it easier to secure your data and have all requests for it go through a centralized place.

Data cleaning, formatting, and organization

Databases store data for many reasons, and your frontend is only one of many consumers of that data. The world doesn’t revolve around you! The data you’re storing about tweets is primarily for using to display on people’s homepages, but there’s actually a lot more your team might be doing with it: