DEV Community: brandon

Data Acronym Overload: ETL vs ELT, Data Lakes vs Warehouses, Parquet vs CSV, and More

brandon — Thu, 30 Jan 2025 19:38:41 +0000

When I started building Outerbase my goal was to make accessing data simpler, but it felt like I was fighting an uphill battle. Everyone was throwing acronyms around left and right — ETL, ELT, CDC, CRDT, the list goes on... It would sometimes be hard to follow even the simplest conversations.

If you've ever felt the same way, stick around. I want to talk about some of the most confusing ones and show you that they are not as scary as they sound.

ETL vs ELT: What’s the Difference?

ETL (Extract, Transform, Load) is the classic data integration process. You extract data from a source, transform it into a usable format, and load it into a target system (like a data warehouse). ETL is great when you need clean, structured data ready for analysis.

ELT (Extract, Load, Transform) flips the script. You extract and load raw data first, then transform it within the target system. ELT is ideal for modern data lakes, where storage is cheap and processing power is high.

The key difference? ETL transforms data before loading; ELT transforms it after. ETL is like cooking a meal before serving it. ELT is like serving the ingredients and cooking them at the table.

Data Lake vs Data Warehouse: Which One Do You Need?

A Data Warehouse is a structured storage system designed for analytics. It’s like a library: everything is organized, indexed, and easy to find. Data warehouses are perfect for business intelligence (BI) and reporting.

A Data Lake is more like a dumping ground. It stores raw, unstructured data—text, images, logs, you name it. Data lakes are flexible and scalable, but they require more effort to organize and analyze.

So, which one should you use? If you need fast, reliable analytics, go with a data warehouse. If you’re dealing with massive, diverse datasets and don’t mind some extra work, a data lake might be better.

Parquet vs CSV: The File Format Showdown

CSV (Comma-Separated Values) is the simplest way to store data. It’s human-readable, lightweight, and works with almost any tool. But CSV files can be slow to process and take up a lot of storage.

Parquet is a columnar storage format designed for efficiency. It compresses data, reduces storage costs, and speeds up queries. Parquet is ideal for big data workloads, but it’s not as easy to read or edit as CSV.

Think of CSV as a plain text file and Parquet as a zipped folder. CSV is great for small, simple datasets. Parquet is better for large, complex ones.

Other Confusing Data Terminology

The data world has no shortage of confusing terms. Here are a few more you might encounter:

ACID vs BASE: ACID (Atomicity, Consistency, Isolation, Durability) ensures reliable transactions in relational databases. BASE (Basically Available, Soft state, Eventual consistency) prioritizes availability and scalability in distributed systems.

OLTP vs OLAP: OLTP (Online Transaction Processing) handles real-time transactions, like sales or payments. OLAP (Online Analytical Processing) focuses on complex queries and data analysis.

CDC (Change Data Capture): A method for tracking changes in a database, so you can replicate or act on them.

ERD (Entity Relationship Diagram):

For more definitions, we put together a handy glossary.

Why This Matters

Understanding these terms isn’t just about sounding smart. It’s about making better decisions. If you confuse ETL with ELT, your team might build a pipeline that’s too slow or expensive. If you mix up data lakes and warehouses, you might end up with a system that can’t handle your needs.

The goal is to choose the right tool for the job. And to do that, you need to know what each tool does.

Conclusion

If you ever feel swamped by these acronyms, know you’re not alone. Even seasoned pros sometimes need a quick refresher. But once you get the hang of terms like ETL vs ELT, Data Lake vs Data Warehouse, and Parquet vs CSV, you’ll find the data world a lot less daunting.

If you still see words you don’t recognize, checking a glossary or official docs can help. In time, all these abbreviations will become familiar old friends—and that’s when you’ll truly feel at home in data.

Now go forth and build something great!

The Best SQLite Browser

brandon — Mon, 27 Jan 2025 18:12:00 +0000

Hello again — it's Brandon, your friend from Outerbase, and today I'm back with another exciting deep-dive into the data world. Today we're going to be talking about browsing SQLite databases. SQLite is already incredibly easy to set up and get started with, but have you ever asked yourself, what if it was even easier to use? That's where a SQLite browser comes into play.

What is a SQLite Browser?

SQLite is beloved for its simplicity. It’s just a single file on your machine, but inside that file you can have lots of tables, columns, and rows of data. Yet even something as simple as SQLite benefits from a visual interface. Many users want a db browser for sqlite. However when they start looking for one all they come across are outdated tools or half-baked side projects.

That’s where Outerbase Studio comes in. It’s an open-source, lightweight data management tool that runs in your browser, on your desktop, or even from the command line. And if you’re juggling more than SQLite — like MySQL or PostgreSQL — you can still do it all in one place. And did I mention it's open-source?!

Why SQLite Still Matters

Despite the flood of bigger databases, SQLite remains a staple. Many applications use it for local data storage, and plenty of developers stick with SQLite for side projects. It’s fast, portable, and dependable. But if you want a quick way to view your tables, run queries, or edit rows, the raw command-line interface can feel clumsy.

That’s what led people to build db browsers for SQLite—simple tools that let you click through your data. When you open an SQLite database with a good GUI, you instantly see your tables and columns. You can even edit rows right on the spot. It’s easy, and it makes working with SQLite as smooth as possible.

Meet Outerbase Studio

Outerbase Studio began as a simple GUI for LibSQL and SQLite-based databases. Over time, it grew into a flexible system that works with MySQL, PostgreSQL, and other databases too. Because it’s open source, you can also see what’s under the hood on GitHub.

Use it in your browser if you like to move fast and hate installing extra tools. Or grab the desktop version (Windows or Mac) for a local experience. It’s powered by Electron, so you can access additional drivers that might not work as easily in a purely web-based app.

Key Features for SQLite Users

Outerbase Studio is more than a viewer. It offers features that make it an all-in-one SQLite browser for editing data, tweaking schemas, and organizing queries.

Powerful Data Editor
- Add, remove, or filter rows instantly.
- Preview any change you make, and commit only when you’re ready.
- A row detail sidebar and foreign key picker help you see how data is linked across tables.
Save & Organize Queries
- Keep your SQL in tidy files, each in its own folder.
- Open several files in distinct tabs. This way, you don’t lose track of your ongoing work.
Table Structure & Schema Editing
- Create or modify columns visually, with no need to recall the exact SQL syntax.
- Rename columns or switch data types in a few clicks.
Notebooks (Coming in 2025)
- Combine queries, code, and explanatory text in one place.
- Perfect for documenting your work or sharing insights with teammates.
Connection Manager
- Store your connection details locally in your browser or app.
- Share them across multiple devices if you’re working in a team.

Expanding Beyond SQLite

If you ever decide to move past SQLite, Outerbase Studio can grow with you. It supports MySQL and PostgreSQL, with more databass coming soon. That means you can use the same clean interface for your next project, even if it runs on a remote server. You won’t have to learn a new GUI each time you switch databases.

Desktop vs. Browser

One of the nicest perks about Outerbase Studio is flexibility. If you’re a fan of web apps, you can launch it in your browser with no installation. If you prefer a local setup, download the Desktop App. It’s still lightweight, and it comes with the same streamlined features.

Why Outerbase Studio Makes SQLite Easier

• No command line hassle. If you just need to update a row or add a column, it’s simpler to click than to memorize a specialized SQL statement.

• Built to reduce friction. Inner workings like table joins, or referencing foreign keys, are made instantly visible. The best GUIs let you see what you’re doing, so you don’t spend time guessing.

• Open source freedom. If you’re curious about how it works, or want to contribute a new feature, you can do so on GitHub.

The Best SQLite Browser

There’s no shortage of SQLite browser out there, but many look and feel dated or unfinished. Outerbase Studio aims to be clean, fast, and open. If you want to see it in action:

Visit Outerbase Studio online to launch it instantly in your browser.
Hop over to GitHub if you want to download the desktop app or peek at the source code.

You’ll be running queries and editing your SQLite data in minutes, minus the heavy overhead of older database tools.

Conclusion: Go Beyond Local with Outerbase’s Cloud Offering

SQLite may be great for local work, but if you want to bring your database closer to users around the globe, Outerbase has you covered. By pairing the simplicity of a modern db browser for SQLite (Outerbase Studio) with our cloud platform, you can push your local database to the edge. That means your app can respond faster, scale on demand, and stay cost-efficient by spinning down when not in use.

Through our managed StarbaseDB offering, you’ll get HTTPS and WebSocket endpoints for low-latency access, plus easy imports, exports, and transaction support. You can even bind ready-made microservices—like user authentication—to get up and running quickly. And we’re constantly adding new features, from point-in-time rollbacks to row-level security, to make your life easier.

So if you’re craving a straightforward SQLite browser for local dev, Outerbase Studio does the trick. And when you’re ready to scale across the globe, move that same SQLite file to our cloud platform. You’ll keep the same familiar interface but gain the power of hosting on the edge. It’s a path that grows with you, from quick prototypes to high-traffic apps, without losing the simplicity that drew you to SQLite in the first place.

Top 5 Data Visualization Libraries You Should Know in 2025

brandon — Sat, 25 Jan 2025 01:29:17 +0000

Hello again — it's Brandon from Outerbase an AI Data Platform. As you can probably imagine I get the privilege to work with a lot of data. And like most sane people I prefer to visualize my data in the form of charts vs. navigating tables, rows, and columns all day (although those people do exist).

Contrary to what most BI tools want you to believe, charts and graphs can actually be beautiful, and helpful. However, with so many libraries out there, choosing the right one can feel overwhelming.

Here are five that I keep an eye out on:

Shadcn
Tremor
Astra UI by Outerbase
visx
nivo

If you are serious about building some next-level, eye-candy data viz, you're going to find what you’re looking for in one of the libraries below.

1. shadcn

shadcn if you're in the frontend world you most likely heard of them. shadcn is a Vercel backed component library who recently introduced their chart components. shadcn sits on top of Recharts and it provides chart components that look great from the start. You can copy and paste them into your app and still leverage Recharts’ full capabilities.

I like that shadcn doesn’t lock users into custom abstractions. When Recharts updates, tjhey don’t have to wait on shadcn to catch up. Instead users can adopt those new features right away.

Here’s a quick example of what this might look like:

import { Bar, BarChart } from "recharts"
import { ChartContainer, ChartTooltipContent } from "@/components/ui/charts"

export function MyChart() {
  const data = [
    { label: 'Jan', value: 30 },
    { label: 'Feb', value: 55 },
    { label: 'Mar', value: 40 },
  ];

  return (
    <ChartContainer>
      <BarChart data={data}>
        <Bar dataKey="value" />
        <ChartTooltip content={<ChartTooltipContent />} />
      </BarChart>
    </ChartContainer>
  )
}

Why Shadcn?

Attractive defaults with minimal setup.
Based on Recharts, so it’s easy to extend.
Pull in Recharts updates whenever you want.

2. Tremor

Tremor is a library of React components for charts and dashboards, and surprisingly enough they too were just acquired by Vercel (I'm sensing a pattern here...) It has 35+ open-source pieces built on React, Tailwind CSS, and Radix UI. It’s a popular choice for anyone who wants production-ready visuals without a lot of fuss.

Tremor also focuses on accessibility and keyboard navigation. If you need a quick dashboard with minimal friction, Tremor is worth a look.

Here’s a short sample code snippet:

import { Card, Title, BarChart } from '@tremor/react';

export default function Example() {
  const chartData = [
    { day: 'Mon', sales: 10 },
    { day: 'Tue', sales: 20 },
    { day: 'Wed', sales: 15 },
  ];

  return (
    <Card>
      <Title>Sales Overview</Title>
      <BarChart
        data={chartData}
        dataKey="day"
        categories={["sales"]}
        colors={["blue"]}
      />
    </Card>
  );
}

Why Tremor?

Clean defaults and beautiful styling.
Large set of UI elements, not just charts.
Good accessibility baked in.

3. Astra UI by Outerbase

Astra UI is a web-component library built on top of Apache ECharts. Because it’s using ECharts under the hood, the customization options are basically endless. The web component approach is really interesting — it means you can embed these charts anywhere, whether you are using React, Vue, Svelte, or just plain ole HTML.

A big plus is how Astra UI integrates with Outerbase's data platform. For instance Outerbase can provide live - updating data via their CDC (Change Data Capture) system, so your charts can always be up to date.

Here’s a short example:

<astra-composed-chart
  type="line"
  data={stocksData}
  keyX="Date"
  keyY="Close"
  width="600"
  height="400"
  header="Stock Prices"
  subheader="Daily closing prices"
></astra-composed-chart>

Why Astra UI?

Powered by Apache ECharts, so it’s both powerful and flexible.
Web components mean you aren’t tied to a specific framework.
Live-updating charts are possible with Outerbase’s CDC.

If you’re already using Outerbase or want a simpler path to real-time data, Astra UI might be a strong choice. Outerbase's AI can even automatically generate the charts for you.

4. visx

visx is a lower-level set of visualization primitives from Airbnb. It uses D3 under the hood but exposes everything as React components. I like visx for situations where I need total control over how my data is displayed, right down to the smallest detail.

visx is also unopinionated about styling, so it lets me bring my own approach for animations, state management, or theming. That can be good or bad, depending on how much structure you like in a library.

Here’s an example of a grouped bar chart with visx:

import { BarGroup } from '@visx/shape';
import { Group } from '@visx/group';
import { scaleBand, scaleLinear, scaleOrdinal } from '@visx/scale';

export function MyVisxChart({ data }) {
  const x0Scale = scaleBand({
    domain: data.map(d => d.category),
    padding: 0.2,
    range: [0, 400],
  });

  const x1Scale = scaleBand({
    domain: ['valueA', 'valueB'],
    padding: 0.1,
    range: [0, x0Scale.bandwidth()],
  });

  const yScale = scaleLinear({
    domain: [0, Math.max(...data.flatMap(d => [d.valueA, d.valueB]))],
    range: [300, 0],
  });

  const colorScale = scaleOrdinal({
    domain: ['valueA', 'valueB'],
    range: ['#008080', '#800080'],
  });

  return (
    <svg width={500} height={400}>
      <Group left={50} top={50}>
        <BarGroup
          data={data}
          keys={['valueA', 'valueB']}
          height={300}
          x0Scale={x0Scale}
          x1Scale={x1Scale}
          yScale={yScale}
          color={colorScale}
        />
      </Group>
    </svg>
  );
}

Why visx?

Very flexible and unopinionated.
Lets you build truly custom visualizations.
Splits into multiple packages, so you can keep your bundle size small.

5. nivo

nivo is another React library that relies on d3 under the hood. It offers a huge variety of chart types and is helpful if you need server-side rendering. I also like that it uses react-spring for smooth transitions and animations.

One of my favorite features is its playground, which lets you experiment with chart configurations and see the changes live. Here’s a basic example of a bar chart in nivo:

import { ResponsiveBar } from '@nivo/bar'

const data = [
  { country: 'AD', hotDog: 75 },
  { country: 'AE', hotDog: 92 },
];

export const MyBarChart = () => (
  <div style={{ height: 400 }}>
    <ResponsiveBar
      data={data}
      keys={['hotDog']}
      indexBy="country"
      margin={{ top: 50, right: 50, bottom: 50, left: 60 }}
      colors={{ scheme: 'category10' }}
      borderColor={{ from: 'color', modifiers: [['darker', 1.6]] }}
      axisBottom={{
        tickSize: 5,
        tickPadding: 5,
        tickRotation: 0,
        legend: 'Country',
        legendPosition: 'middle',
        legendOffset: 32,
      }}
    />
  </div>
);

Why nivo?

Tons of chart types out of the box.
Server-side rendering for SEO or performance needs.
Smooth animations and transitions via react-spring.

Conclusion

Choosing the right data visualization library depends on the job at hand. If you're already using nextjs and want something fast, Shadcn is a good bet. Tremor is handy if you need a whole dashboard solution without writing everything from scratch. If you value powerful, customizable, and beautiful charts out of the box, Astra UI by Outerbase might be perfect. visx is great if you prefer building things from the ground up, and nivo is a strong option if you want a wide range of chart types with advanced transitions or server-side rendering.

I always remind myself that the best charting library is the one that helps me (and my users) see and understand the data the fastest. If you’re looking for a self-hosted or hosted platform to manage your data—and want an easy way to embed live-updated charts—check out Outerbase with Astra UI. It’s a neat solution that doesn’t force you to build it all out myself.

Above all, data visualization should be clear, quick, and delightful. These libraries each take a different path to that same goal. Whichever you choose, I hope you have fun turning your data into insights.

Exploring OpenAI Operator

brandon — Thu, 23 Jan 2025 19:42:27 +0000

What Is Operator?

Have you ever wished you could push off repetitive online tasks to someone else?

Operator is OpenAI’s answer. It’s an assistant with its own built-in browser. You give it a command — “Buy groceries,” “Fill out this form,” or even “Create a meme” —and it steps in to do the clicks and forms for you. By using screenshots to “see” each webpage, Operator can interact with buttons, menus, or text boxes in a way that feels almost human.

OpenAI's Operator isn't SkyNet yet, running rampant on the web. It always checks with you before doing anything sensitive, like entering credit card details. That means you stay in control.

Meet CUA (Computer Using Agent)

Operator is powered by CUA, which combines GPT-4o’s vision abilities with logic skills. When it lands on a webpage, it can identify key parts—like sign-up forms or buy buttons—and take action. If it gets confused, it hands control back to you.

Right now, OpenAI hasn’t opened the CUA API for public use, but they say it’s coming soon. That means developers will eventually be able to embed an AI browser directly into their own apps, unlocking major time-savers.

Connect Operator to Your Own Database Securely with Outerbase

A big advantage of using Operator is the ability to log its actions for analysis or auditing. As soon as OpenAI adds Operator to their API, you’ll be able to funnel those logs or data outputs directly into your preferred third-party tool. Data Platforms like Outerbase specialize in storing and querying that data securely in your own database, meaning you own it.

Because Outerbase keeps your data in a private environment, you don’t have to worry about sensitive information leaking into public systems or being locked-in to a single vendor. You’ll get both an AI-powered assistant and a centralized, private place to hold all your logs—ideal for businesses that value confidentiality.

Why Operator Matters

Time Savings: Lowers the friction of repetitive tasks, freeing you to focus on core projects.
Error Reduction: Operator double-checks steps and demands confirmation before risky moves—great for e-commerce and data entry.
Broad Compatibility: Operator treats the web like a normal user, so it doesn’t need special plugins or integrations.
Data Security: Pairing Operator’s capabilities with a secure database tool like Outerbase ensures sensitive logs remain private and compliant.

With this mix of human-like browsing and an easy path to data storage, you can get back to focusing on what is exciting to you and outsource the boring stuff.

Current Limitations

Early Access: Operator is in a research preview for ChatGPT Pro (U.S. only at $200/month).
Complex Interfaces: It can struggle with advanced or unusual design elements on some sites.
High-Stakes Tasks: It refuses banking transfers or high-risk actions, which keeps you safer (but limits some use cases).

Future Plans: Wider Use, CUA API, and Enhanced Workflows

Expanded Availability: Operator will roll out to more plans beyond just Pro accounts.
CUA API Release: Developers will be able to harness Operator’s AI-browsing backbone in their own products.
Deeper Workflow Support: Expect improvements around scheduling, editing docs, or managing long processes.

Once the CUA API goes live, you can combine Operator’s automation with Outerbase to store data in your own secure environment—perfect for teams that need a reliable, private record of everything their AI is doing.

Conclusion

Operator by OpenAI isn’t just another AI model, it’s a browser-savvy agent that can fill forms, make reservations, and generally handle the busywork of the web. For now, Operator is only available through ChatGPT Pro in the U.S., but OpenAI plans to open it to more users and eventually release the CUA API for developers. Then you will be able to pair it with a private database solution like Outerbase, you’ll maintain total control and security of the data it generates.

Best way to learn SQL

brandon — Wed, 22 Jan 2025 19:28:07 +0000

How I Learned SQL (And How You Can Too)

I’m Brandon, CEO and Co-Founder of Outerbase. We provide an AI-powered layer on top of your database that allows you to edit, view, query and visualize your data even faster. However, even with AI's help, it is still good to understand what's going on under the hood. That is why even in 2025 I still recommend learning SQL.

A non-technical friend of mine recently asked me what is the best way to learn SQL. They work as a Product Manager and wanted some basic skills. Here’s how I learned, plus some tips that might help you get going.

Why SQL Matters

SQL (Structured Query Language) is how we talk to relational databases. Here’s why it’s important:

Search and filter data: e.g., “Find all customers who signed up last month.”
Update records in bulk: e.g., add a new column or reset thousands of values at once.
Join related tables: e.g., see product sales alongside customer data.
Secure and structure information: relational tables keep data organized and safe.

Major databases like PostgreSQL, MySQL, and SQL Server all use SQL. Once you know the basics, you can answer data questions on your own.

Step 1: Start With a Tutorial

A structured tutorial helps you learn faster. Some good places to begin:

Intro to SQL on Outerbase – Covers the basics, with interactive lessons right in your browser.
W3Schools SQL Tutorial – Classic text-based examples.
Codecademy: Learn SQL – Interactive approach that walks you through writing queries.

Any of these will give you a strong foundation.

Step 2: Practice With Real Data

Reading about SQL is fine, but you learn the most by writing queries. Spin up a local or cloud database (PostgreSQL, MySQL, or SQL Server) and create a small table:

CREATE TABLE products (
  product_id SERIAL PRIMARY KEY,
  name VARCHAR(255),
  price DECIMAL(10,2)
);

INSERT INTO products (name, price) VALUES
('Laptop', 999.99),
('Mouse', 24.99),
('Keyboard', 49.99),
('Monitor', 199.99);

Try a few queries:

-- Fetch all products:
SELECT * FROM products;

-- Find the product with the highest price:
SELECT name, price
FROM products
ORDER BY price DESC
LIMIT 1;

Seeing actual results is the quickest way to learn.

Step 3: Solve Real Problems

It sticks better if you connect SQL to real situations. Think about questions that matter to you:

Which item has the highest price?
Change the price of all “Mouse” items to 19.99.
Delete items cheaper than $25.

Here’s how that might look:

-- 1. Most expensive item:
SELECT name, price
FROM products
ORDER BY price DESC
LIMIT 1;

-- 2. Update 'Mouse' price:
UPDATE products
SET price = 19.99
WHERE name = 'Mouse';

-- 3. Delete cheap items:
DELETE FROM products
WHERE price < 25.00;

Practicing on real projects cements your new skills.

Step 4: Focus on Core Commands First

SQL is big, but most of the time you’ll use these:

SELECT (fetch data)
WHERE (filter rows)
JOIN (connect multiple tables)
GROUP BY (aggregate rows, often with COUNT, SUM, or AVG)
ORDER BY (sort results)
INSERT (add new rows)
UPDATE (change existing rows)
DELETE (remove rows)

For more info:

These microsites let you run queries in your browser on a real database.

Step 5: Learn Indexing and Performance

As your skills grow, you’ll want your queries to run faster. That’s where indexing helps. For example, in PostgreSQL:

CREATE INDEX idx_price
ON products (price);

Now the database can find rows faster when sorting or filtering by price. To learn more, check out the PostgreSQL Docs or MySQL Docs.

Step 6: Browse Stack Overflow Q&A

Stack Overflow has a massive library of SQL questions and answers. For example, someone might ask how to use GROUP BY:

SELECT product_id, SUM(price) AS total_price
FROM products
GROUP BY product_id
ORDER BY total_price DESC;

Explore the SQL tag on Stack Overflow to see common questions and solutions.

SQL Tips for Product Managers

Learn Enough to Be Effective You only need enough SQL to answer your own questions without waiting on others.
Use a Sandbox Experiment in a test environment, not on production data. Everyone makes mistakes at first.
Ask for Help AI, Data engineers, and developers can save you time when you get stuck.
Know Your Limits Hand off complex or performance-heavy queries to AI or specialists.

More Useful Resources

Intro to SQL on Outerbase – Interactive, browser-based tutorials using SQLite.
W3Schools SQL Tutorial – Classic, text-based lessons.
Codecademy: Learn SQL – Step-by-step lessons with instant feedback.
PostgreSQL Docs – In-depth details about PostgreSQL.
MySQL Docs – Official reference for MySQL.
SQL Server Docs – Microsoft’s official SQL Server resource.

Final Thoughts

You can learn SQL basics in a few days. Mastering it can take a lifetime, but you don’t have to be a pro to do useful things. Once you know SELECT, JOIN, and GROUP BY, you’ll be amazed how many questions you can answer yourself.

Want to jump in? Try Intro to SQL on Outerbase or a guided course on Codecademy or W3Schools. The key is to write real queries and see how the database reacts.

What is a database schema?

brandon — Mon, 20 Jan 2025 17:54:52 +0000

I remember the first time I heard someone mention a “database schema.” It feels like forever ago now... I was working on a side-project, trying to spin up a backend based on some of my spreadsheets and some .txt files, and it felt overwhelming. I kept thinking there had to be a better way to organize everything. That’s when my buddy told me: “Sounds like you need a proper database with an actual schema.” Let me tell you, they were right.

What is a database schema?

At its heart, a database schema is just a map, or a blueprint, showing how your data fits together. It describes which tables exist, how columns are named, and how tables relate to one another. When you have a schema, you don’t have to dig around to figure out what data goes where; the schema spells that out for you.

If you’ve ever faced a folder stuffed with random files, you know how confusing unorganized data can be. A schema fixes that problem by defining how information fits together.

Schema on Read vs. Schema on Write

You’ll come across two terms when people talk about schemas:

Schema on Write:
You define the schema before storing the data. It forces data to be structured right from the start.

Schema on Read:
You load raw data with minimal structure and only apply a schema later, like when you query it. This can be flexible, but sometimes you end up wrestling with messy data at query time.

Each method has its place. If you need fast and reliable queries, or your data often comes in a predictable format, schema on write can be a lifesaver. But if you’re dealing with sprawling datasets where structure changes quickly, schema on read might fit better.

Common ways to organize your data

Relational Model
Picture rows and columns bound together by relationships. This is a standard approach in most well-known database systems.

Star Schema
A central “fact” table sits in the middle, surrounded by “dimension” tables. Facts are typically numbers (like sales figures), while dimensions describe context (like product name or date).

Snowflake Schema
Like a star schema, but with more branching in the dimension tables. It can give you deeper detail but increase complexity.

Hierarchical Model
Data arranged in a tree. Each node can have child nodes branching off. Great if your data naturally forms a hierarchy, like store departments and sub-departments.

Flat Model
All data goes into a single table, which might be fine for small projects but becomes unruly as you grow.

Network Model
Links data in a graph of nodes, allowing more complex connections. Less common today, but it can handle many-to-many relationships nicely.

How to design database schemas

Designing a schema starts with conversations. Ask people: “What data do you have?” “What questions do you need answered?” That set of questions guides the tables, columns, and the relationships you’ll build. Once you start drafting a schema, feedback loops are key. You bounce the design off others, add missing tables, or clarify fuzzy logic. Sometimes you draw it on a whiteboard or use a modeling tool.

Once the blueprint feels right, you build the actual database. You load the data, run some test queries, and see if everything behaves. If something’s slow or doesn’t logically fit, you tweak it.

Best practices for database schemas

Use Clear Names
Call a date field OrderDate if it tracks orders, not just “Date.” It might seem obvious, but clarity saves headaches later.

Normalize (But Not Too Much)
Normalization helps you avoid repeating data (like storing a customer’s address in ten different places). It also keeps things tidy, but you do want to allow enough duplication to maintain speed and usability.

Plan for Security
Some data is private—store login info or personal details in a secure table. Limit who can edit production data. It’s small details like these that keep you safe.

Document Everything
When you add a new table, write a sentence or two about what it’s for so new team members (or your future self) can quickly get up to speed.

Two main kinds of database schemas

Logical Schema
Shows you the logical arrangement of data: which tables are there, what columns they have, and how they link together.

Physical Schema
Works behind the scenes, revealing how data is actually stored on disk or in memory. You usually don’t have to stress over the exact storage mechanism — your database handles that.

Why it's worth it

Good schemas are like well-designed city streets: you can navigate easily, and you don’t get stuck in endless detours or dead ends. It’s rarely fun to wade through disorganized data. With a database schema, you see pattern and purpose rather than chaos. You gain faster queries, fewer inconsistencies, easier collaborations, and a system you can grow.

Should you use a database schema?

When I first discovered database schemas, they felt like an extra chore. But I quickly realized they were the only thing standing between me and the kind of data breakdown that leaves you frustrated and confused. With the right schema, you can unlock the full power of your data—whether that’s for a personal project or a large-scale application.

So if you find yourself drowning in a sea of spreadsheets or puzzling over how to connect different pieces of information, take a moment to build a schema. You’ll thank yourself later.

5 AI-Powered Developer Tools Changing the Way We Work in 2025

brandon — Sat, 18 Jan 2025 16:58:17 +0000

Introduction:

Whether you are excited about it or not, AI is not just a passing trend — it's here to stay. AI now helps developers write code, design interfaces, analyze data, create documentation, and even review code. With almost every single tool labeled “AI-powered,” figuring out which ones that can truly help you feels daunting. In this article, I explore five dependable AI tools and suggest a few alternatives, so you can pick the best option for your workflow and improve your efficiency.

1. AI Code Editor: Cursor

Replaces: VS Code

Cursor is probably the most popular AI code editor that exists. It works with you through your entire journey writing code. It helps with autocompletion, code generation, and with it's new agent workflow it can build and navigate entire apps for you.

Alternative to consider:

Windsurf – A new code editor that rivals established tools by offering powerful AI capabilities.

2. AI Design Tool: v0

Replaces: Figma

v0 uses AI to streamline your design process. It offers automated layout suggestions, quick prototypes, and an easy-to-use chat interface, and even generates the code for you so you spend less time setting up and more time improving your designs.

Another design tool:

Magic Patterns – Use AI to create custom components and pages with minimal effort.

3. AI Data Platform: Outerbase

Replaces: DataGrip, Tableau

Outerbase combines database management with data visualization. Its user-friendly interface makes querying and analyzing data straightforward, helping teams see insights faster and make better decisions.

Check out this tool as well:

ThoughtSpot – An BI solution that uses AI for in-depth analytics.

4. AI Documentation Platform: Mintlify

Replaces: Docusaurus

Mintlify lets you create clear, SEO-friendly documentation without a heavy setup. It offers version control, full-text search, and simple customization, making it easy to keep your docs organized.

Other documentation solution:

Notion AI – Helps you write and organize documentation quickly.

5. AI Code Review Tool: CodeRabbit

Replaces: Traditional Pull Request Reviews

CodeRabbit adds AI insights to the code review process. It scans for possible errors, offers suggestions for improvements, and keeps your codebase tidy. It also helps reviews go faster while still maintaining quality.

Another tool to consider:

Greptile – Uses AI to understand your codebase, review pull requests, detect bugs, and streamline tasks.

Conclusion

I truly believe these 5 AI-powered devtools are changing the way developers work. Whether you’re writing code, designing user interfaces, analyzing data, documenting projects, or reviewing code, there’s already an AI tool ready to speed things up.

Try them out, compare features, and pick the ones that fit your workflow best.

Postgres vs. MySQL

brandon — Thu, 16 Jan 2025 17:38:23 +0000

Hello I'm Brandon, I’m the CEO & Co-founder of Outerbase, where we are building a modern data platform. We work with thousands of developers managing their data every day, and I’ve seen firsthand how PostgreSQL and MySQL stand out as two of the most popular (and powerful!) databases. In this article, I’ll compare both—covering their strengths, weaknesses, and nuanced differences — so you can decide which one suits your needs best.

Relational databases have powered countless applications for decades, and they remain the backbone of many modern systems. When it comes to production-ready options there are two that stand out as the most widely used, PostgreSQL and MySQL. Both deliver solid performance, reliability, and community support, but there are notable differences in the way they handle data, their feature sets, and how easy they are to configure. Understanding these nuances can help you pick the right one for your specific needs.

TL;DR – When Should You Use PostgreSQL or MySQL?

The table below summarizes some of the biggest differences at a glance:

Criterion	PostgreSQL	MySQL
Data Model	Advanced (schemas, custom types, JSON)	Simpler (distinct databases)
Complex Queries	Excellent (window functions, CTE)	Adequate, but fewer advanced capabilities
Performance	Strong in complex writes, concurrency	Strong in read-heavy workloads
Extensibility	Highly extensible (custom functions)	More limited, but large ecosystem
Licensing	PostgreSQL license (BSD/MIT-like)	GPL + commercial license from Oracle

Feature Overview

PostgreSQL
PostgreSQL uses schemas to organize data within a single database, giving teams fine-grained control over permissions and logical data partitions. It also supports a wide range of data types, including JSON, arrays, ranges, and even custom-defined types, making it attractive for applications that handle complex or semi-structured data. The database uses Multi-Version Concurrency Control (MVCC) to reduce lock contention, so it typically excels at heavy write loads and complex queries that benefit from features like window functions and Common Table Expressions (CTEs). Another key strength is extensibility: you can add custom functions, operators, or extensions such as PostGIS for geospatial data—handy if your application requires specialized capabilities.

MySQL
MySQL, on the other hand, organizes data more simply, using distinct databases rather than schemas. This can make life easier for smaller projects or teams that want to keep data isolated by simply spinning up a new database. One of MySQL’s biggest selling points is its strong performance in read-heavy scenarios, especially when the InnoDB engine is paired with proper indexing and caching. It’s also known for straightforward replication, which many high-traffic websites use to distribute read operations across multiple servers and deliver faster responses to users around the globe. MySQL is generally easy to set up and has a vast knowledge base, which is appealing if you need to get a project off the ground quickly or if your team is already familiar with the MySQL ecosystem.

Database Details

Read/Write Throughput
MySQL typically shines in handling read-intensive workloads, provided that indexes and caching layers are properly tuned. Some large-scale users, such as Uber, have found success with MySQL even for hefty write loads, once the database is carefully configured. For straightforward inserts and updates, MySQL can match PostgreSQL in many benchmarks. However, PostgreSQL often takes the lead with more complex writes and intricate queries. Its concurrency features, enhanced by MVCC, reduce lock contention and allow it to maintain high performance in scenarios that involve numerous transactions simultaneously. With proper tuning, PostgreSQL can match or exceed MySQL’s performance in typical OLTP or analytical workloads.

Scalability
Both databases scale well, but they do so differently. PostgreSQL responds favorably to vertical scaling—adding more CPU, RAM, or faster storage often yields significant benefits. Horizontal scaling is a bit more involved; tools like PgBouncer for connection pooling and logical replication can help, and large platforms like Instagram and Notion have demonstrated that it can support vast user bases. MySQL has long been praised for its straightforward replication (master-replica), making it easy to offload read traffic and distribute those queries across multiple servers. This built-in replication setup is often enough for many use cases where global read scalability is paramount.

Indexing and Query Optimization
PostgreSQL provides diverse index types, such as B-tree, GiST, GIN, and BRIN, which cater to specific types of queries and can significantly enhance performance. It also has sophisticated JSON indexing and full-text search capabilities, though you may need to enable certain extensions. MySQL’s InnoDB engine primarily relies on B-tree indexes, suitable for most common query patterns, and it has some full-text indexing capability—though not as extensive as PostgreSQL’s.

Performance Tuning
Both PostgreSQL and MySQL require tuning parameters (e.g., buffer sizes, caching, checkpoint intervals) to optimize performance. PostgreSQL can be more involved, especially for new users, but with well-designed indexes and queries, either database can scale effectively in most production environments.

Recent Trends and Recognition
In recent years, PostgreSQL has been gaining popularity at a rapid pace, earning accolades like DBMS of the Year and making strides in developer surveys. Its permissive license and modern feature set continue to draw new users. Nonetheless, MySQL remains the most installed open-source relational database worldwide, fueled by Oracle’s backing and an enormous community. Its stability, simplicity, and ecosystem of hosting providers and tools ensure its continued dominance in many scenarios.

License Considerations
MySQL’s Community Edition is GPL licensed, which can be restrictive if you want to keep your own code proprietary. In that case, a commercial license from Oracle might be necessary. PostgreSQL’s license is similar to BSD/MIT, carrying fewer restrictions and no requirement to disclose your source code.

Technical Comparison
PostgreSQL’s object hierarchy is structured as Databases → Schemas → Tables, whereas MySQL uses Databases → Tables. PostgreSQL is fully ACID-compliant and can handle DML and DDL transactions; MySQL is also ACID-compliant through the InnoDB engine, and supports atomic DDL in version 8.0+. On the security front, PostgreSQL provides Row Level Security (RLS) out of the box, whereas MySQL requires workarounds such as views or stored procedures to mimic similar functionality.

In terms of replication, PostgreSQL supports both physical (WAL-based) and logical (pub/sub) methods. MySQL uses the binary log to facilitate logical replication and is commonly configured for read scaling with master-replica setups. JSON handling is more comprehensive in PostgreSQL, thanks to its robust indexing and array of functions. While MySQL also includes JSON features in version 8.0+, its indexing for JSON data is somewhat limited. PostgreSQL’s window functions and CTEs are more mature, although MySQL has caught up by adding these features recently. If you value extensibility, PostgreSQL offers a wide array of extensions—PostGIS for geospatial use cases, pg_stat_statements for detailed query insights, and the ability to define custom data types—while MySQL’s customization options focus on stored procedures and plugins.

Postgres vs MySQL Performance

In tests using Go clients with similar configurations:

Insert (Write) Test
- Setup: Multiple virtual clients continuously insert randomized records.
- Results:
  - PostgreSQL hovered around 19,000 inserts/second on a 4-CPU server with an SSD, versus MySQL’s 10,000.
  - PostgreSQL showed lower latency at the 99th percentile and used CPU, disk, and memory more efficiently.
  - MySQL performance dropped around 5,500 queries/second, incurring higher CPU usage.
Select (Read) Test
- Setup: Queries involved a random event ID joined against a ~70-million-row customer table.
- Results:
  - PostgreSQL again displayed lower latency, scaling nicely up to ~32,000 queries/second.
  - MySQL started showing latency spikes closer to 18,000 queries/second, tied to rising CPU usage.
  - Both eventually reached CPU saturation, but PostgreSQL stretched further before hitting a wall.

Key Takeaways

Write Efficiency: PostgreSQL handled heavy insert loads with less resource usage.
Read Performance: MySQL did well initially but dropped off sooner under high concurrency.
Resource Utilization: PostgreSQL generally used fewer system resources at equivalent loads.

Real-world performance will vary depending on hardware, indexing strategy, query patterns, and configuration. Always test in an environment that reflects your production setup before making a final choice.

To simplify testing and working with both Postgres and MySQL, Outerbase offers a powerful interface for exploring, querying, and visualizing your databases. Whether you're comparing benchmarks or managing production workloads, Outerbase can help streamline your process.

So, Postgres vs MySQL which is Better

Consider PostgreSQL If
- You need advanced features like window functions, CTEs, custom data types, or PostGIS for geospatial queries.
- You expect complex or highly concurrent workloads.
- You want a more permissive license with fewer restrictions.
- You’re eager to tap into a rapidly expanding ecosystem and community.
Consider MySQL If
- Your primary focus is read-heavy workloads with straightforward queries.
- You want something quick and simple to deploy, backed by a massive knowledge base.
- Your team already knows MySQL, or your hosting environment is optimized for it.
- You prefer easy replication for horizontal scaling.

The best approach is often to test both. Spin up a few instances, replicate your real-world workload, and see how each performs. You might discover one database naturally suits your data and query patterns better, especially once you factor in how comfortable your team is with each technology.

Conclusion

You might favor PostgreSQL if you need advanced features like window functions, CTEs, custom data types, or PostGIS for geospatial work. It also excels with heavier concurrency or complex workloads, and its permissive license won’t impose many restrictions on your own code. Meanwhile, MySQL remains a compelling choice if your application is read-heavy and you want something quick to deploy, especially if your team is already familiar with MySQL or your environment is optimized for it. Its simpler replication mechanisms are convenient for those who need to scale out reads.

In the end, the best approach is to test both databases in an environment that mirrors your production setup. Examine how they perform with your actual data, queries, and concurrency levels. The “better” option often comes down to factors like feature requirements, workload profiles, operational familiarity, licensing, and long-term scalability goals. While PostgreSQL’s feature set is attracting a fast-growing user base, MySQL’s proven track record and massive community ensure it will remain a mainstay for years to come.

If you need an easy way to test both Postgres and MySQL please check out our open-source repo Outerbase Studio which gives you the ability to view, edit, query and even deploy them both.

Thanks for Reading! If you have any further suggestions or want to see additional metrics, don’t hesitate to reach out.

Shout out to Anton P for the benchmarking.

The evolution of Serverless Postgres

brandon — Thu, 30 May 2024 16:21:07 +0000

Among the many options available for running managed Postgres, Amazon Aurora Serverless initially stood out as unique when it was announced. It promised to introduce the concepts of scaling to zero, autoscaling, and usage-based pricing to Postgres.

A lot has changed since then, including AWS's decision to deprecate scale-to-zero in Aurora. Today, developers have other options for running serverless Postgres, such as Neon. In this comparison, we'll examine the key differences between Aurora and Neon, focusing on their serverless capabilities and pricing models.

Navigating the Amazon Aurora universe

Let’s start by clarifying terminology. When developers refer to “Amazon Aurora”, they might be referring to three different products:

Amazon Aurora provisioned is the “traditional” version of Amazon Aurora, where you provision database instances with a fixed capacity. You have to specify the instance size upfront, and you are billed based on the allocated resources regardless of usage.
Amazon Aurora Serverless v1 came next as the first serverless version of Amazon Aurora. The two core functionalities it introduced were scale to zero and autoscaling: Aurora Serverless v1 instances automatically start up, shut down, and scale capacity up or down based on your application's needs. It's positioned as a more optimal choice for applications with intermittent, unpredictable, or variable workloads.
Amazon Aurora Serverless v2 aimed to address the limitations of v1. It claimed to offer more fine-grained scaling, improved performance, and the same high availability and durability as the provisioned instances. But these improvements came at a high price: *losing scale to zero. *

In Aurora Serverless v1, if there were no database connections or activity for a period of time, the database could automatically pause and reduce capacity to zero, effectively eliminating costs during idle periods. This capability was essential to the claim of serverless as a way to reduce costs for applications with “infrequent usage patterns” running in Aurora.

In contrast, Aurora Serverless v2 maintains a minimum capacity of 0.5 ACUs (Aurora Capacity Units) even when there is no database activity. As we’ll explore later in the post, this means that there are always some costs incurred, regardless of usage. This approach was taken to ensure instant provisioning and to eliminate the latency associated with cold starts, but it came with a trade-off in costs for users.

Now, meet Neon

Neon's architecture is inspired by Amazon Aurora and its separation of compute and storage. But Neon takes this design one step further by adopting a custom-built storage engine that keeps a history of Postgres transactions. This enables Neon not only to offer a truly serverless experience with scale to zero, but also to focus on improving development workflows by offering features like database branching.

Neon automatically scales compute instances to zero when inactive for a specified period (5 minutes by default). Similar to Aurora Serverless, it includes autoscaling to dynamically adjust compute resources based on the current load within user-defined limits. Differently to Aurora, Neon comes with a free tier.

Features: Neon vs Aurora Serverless v2

Let’s dig deeper into how Neon compares to Amazon Aurora Serverless in terms of features. This table gives you the high-level view:

Feature	Amazon Aurora Serverless v2	Neon
Scale-to-zero	No, it maintains a minimum capacity of 0.5 ACU at all times*	Yes, instances can be configured to automatically suspend after a period of inactivity
Instant provisioning	No, new instances take up to 20 minutes	Yes, rapid provisioning of new instances (<500ms)
Compute autoscaling	Yes, by 0.5 ACU increments	Yes, based on real-time load
On-demand storage	Yes, by 10 GB increments	Yes, by 2-10 GB increments depending on plan
Database branching	No	Yes, with data and schema via copy-on-write
Multi-AZ replicas	Yes	No, under development
Read replicas	Yes, using separate instances	Yes, without storage redundancy (compute-only)
Point-in-time recovery	Yes, via backups and transaction logs (takes from minutes to hours)	Yes, via database branching (instant)
API support	Yes, via RDS API	Yes, via Neon API
CLI support	Yes, via AWS CLI	Yes, via Neon CLI
Postgres extensions	Limited	Extensive (200+)
Custom extensions	Not supported	Supports custom extensions
Connection pooling	Yes, using RDS Proxy (for a fee)	Yes, integrated within Neon’s architecture
IP Allowlist	Yes, via security groups	Yes, via customizable access control
Organization accounts	Yes, via AWS IAM and AWS Organizations	Yes, natively supported
Integrations	Limited outside AWS ecosystem	Yes, for CI/CD workflows
Support	Yes, at extra cost	Yes, included with plan
Free tier	No	Yes

*If you’re wondering what the heck is an ACU, see the next section.

Pricing model: Aurora Serverless

When it’s time to evaluate pricing for Aurora Serverless, you’ll very quickly be confronted with what seems like an easy question to answer: what is an ACU?

Let’s backtrack. In Aurora Serverless, ACUs (Aurora Capacity Units) are the units of measure used to define the capacity of database instances. When running an instance as a user, you’ll define a minimum and maximum ACU limit. Aurora will scale up and down automatically between these minimum and maximum limits, in 0.5 ACU increments.

The minimum number of ACUs varies between Aurora Serverless v1 and v2:

In Aurora Serverless v1, you can define 0 as the minimum limit (v1 scales to zero).
In Aurora Serverless v2, the minimum possible limit is 0.5 ACU. We’ll break down what this implies cost-wise in the next section.

Now, to size an Aurora Serverless instance, the first thing you would like to know is how much CPU and memory is contained in each ACU. You will be billed according to how many ACUs you have used in a month, so this is highly relevant: for example, you may suspect that 1 CPU would be enough to handle your peak load, and therefore you would like to set up your maximum ACU limit at a corresponding capacity.

Unfortunately, AWS is opaque in disclosing this information, making pricing in Aurora very uncertain. According to the Aurora docs, an ACU is “a combination of approximately 2 gibibytes (GiB) of memory, corresponding CPU, and networking”.

We’re as confused as you are about what this means. Some folks online have experimented with this and concluded that probably 1 ACU = 0.25 vCPU, 2 GiB memory. But we can’t know for sure.

ACU mysteries aside, your monthly Aurora Serverless bill will be calculated as the sum of a few elements, included below. If you avoid the I/O charges by using I/O optimized storage (highly recommended), compute and database storage will most likely be the main elements contributing to your monthly costs.

Billing component in Aurora Serverless	Description
Compute	Billed per ACU-hour based on the capacity used, with a minimum of 0.5 ACU.
Database storage	Billed per GB-month in 10 GB increments with a minimum of 10 GB.
I/O requests	Only applicable to standard storage (included for I/O optimized). Billed per million requests.
Backup storage	Automated backups up to the size of your database are free. Additional backup storage is billed per GB-month.
Data transfer costs	Data transfer within the same AWS region is free. Cross-region and outbound data transfer is billed per GB.
Multi-AZ deployments	Additional costs for the resources used in the additional AZ.
Read replicas	Billed for ACU usage, storage, and I/O operations for each read replica. Cross-region replication incurs additional data transfer charges.
Backtrack	When you “rewind” an Aurora database without restoring from backup. Billed per GB-month for the change records stored.
API	Charges for using certain APIs provided by Aurora. Billed per million API requests.
Snapshot or cluster export	Charges for exporting snapshots or clusters to S3. Billed per GB of snapshot or cluster exported.

Since Aurora Serverless v2 doesn’t have a free tier and has minimum requirements for both compute and storage, we can estimate the minimum costs for the smallest database possible running 24/7:

Minimum monthly cost: $65.65 USD.

This is the absolute monthly minimum for a database running in us-east-1, assuming we’re using I/O optimized storage to avoid extra I/O charges.

This calculation assumes that you’re using 0.5 ACU (the minimum) at all times. However, an important practical consideration is that in reality, you’ll be forced to pick an ACU range, and the lowest maximum ACU possible is 1 ACU. So, a better expectation is that, in the previous example, costs would oscillate between $60 and $120 USD approximately.

Pricing model: Neon

Compute in Neon with autoscaling enabled works similarly to Aurora Serverless, but without the opacity. In Neon, 1 CU = 1 vCPU and 4 GiB of memory. You’ll be able to set up minimum and maximum autoscaling limits (with the minimum being able to scale to zero if you wish), and your compute consumption will be billed in CU-hours at the end of the month.

In terms of billing components, Neon offers three different pricing plans. Your monthly bill will account for:

The monthly fee corresponding to each plan ($0, $19, or $69)
Any additional compute or storage usage over what is included within each plan
Charges per additional projects (the logical equivalent of an instance in Neon)

Billing component in Neon	Free	Launch	Scale
Monthly fee	0 \	19 USD	69 USD
Additional compute usage	N/A - Includes capacity for 24/7 usage with 0.5 CU	300 CU-hours included with monthly fee. Additional charges after that.	750 CU-hours included with monthly fee. Additional charges after that.
Additional storage	N/A - Includes 0.5 GB	10 GB included with monthly fee. Additional charges after that.	50 GB included with monthly fee. Additional charges after that.
Additional projects	N/A - Includes 1 project	10 projects included with monthly fee. Additional charges after that.	50 projects included with monthly fee. Additional charges after that.

Comparing compute costs: Neon vs Aurora Serverless v2

Estimating compute costs is often the hardest piece with serverless databases. To bring some clarity to this, let’s work through some example workloads that teams might see for serverless applications.

For this exercise, we’ll use the following equivalence:

1 ACU in Aurora = 0.5 CU in Neon = 0.5 vCPU, 2 GiB memory.

Taking into consideration that AWS discloses that 1 ACU equals 2 GiB of memory, and that 1 CU in Neon equals 4 GiB of memory, this equivalence seems like a fair assumption—but note that this is approximate. We have reasons to believe that ACUs are even smaller than that CPU-wise, so your** real workload may require higher ACU limits** (and therefore higher costs) than estimated here.

Example workload	Compute costs in Neon	Compute costs in Aurora Serverless v2
Low compute (testing)	41 USD	701 USD
Medium compute (analytics)	69 USD	467 USD
High compute (application)	1,059 USD	4,064 USD

Low compute, testing workloads

Imagine a small team working on a new feature. They need multiple dev, staging, and testing environments, but each environment has minimal traffic and data storage needs. These databases are often idle for extended periods and only need to be active during specific testing windows.

Using database branches, we could do this on the Neon free tier. But, if this workload requires multiple projects, we cand use the Launch tier instead. Let’s say we’re using 1 vCPU (1 CU) for each of our three projects (dev, staging, and testing), but overall, they are idle 80% of the time. So, this becomes:

1 CU * 3 Projects * 730 * 0.2 = 438 CU-hours

This is over the 300 compute hours included in the Launch tier, so we’ll also have to pay $0.16 per extra compute hour:

$19 + (138 compute hours * $0.16) = $41.08

So, just over $40 monthly for this testing workload with Neon. For Aurora Serverless v2, it is:

2 ACU * 3 instances * 730 = 4,380 ACU-hours

This costs us many more compute hours because we have no scale to zero. Now, using the standard configuration pricing of $0.16 per ACU-hour in I/O optimized instances:

4,380 ACU-hours * $0.16 = $700.8

The Aurora compute cost would be 17x more than the Neon cost for this sceario, mainly due to Neon’s ability to scale to zero.

Medium compute, analytics workloads

Here, the team might need to batch-run analytics queries and generate reports to gain insights into user behavior and application performance.

Let’s do Neon first. Let’s assume we’re still in the Launch tier, that we’ll use 2 vCPUs (CUs), and 1 project. Again, these analytics runs aren’t constant—we’ll assume that we’re using them 50% of the time and that they’re idle the rest. With Neon, this looks like:

2 CUs * 1 Project * 730 * 0.5 = 730 CU-hours

If we stayed on the Launch tier, we’d have to pay 430 extra compute hours, so the extra cost would be:

$19 + (430 CU-hours * $0.16) = $448.8

*We can get this cost much lower if we upgraded to the Scale tier, which includes 750 CU-hours within the $69 monthly fee. *

With Aurora Serverless v2, we get:

4 ACUs * 1 Instance * 730 = 2,920 ACU-hours

Again, if we assume a I/O-optimized storage so we’re not abused by I/O costs, the monthly price would be:

2,920 ACU-hours* $0.16 = $467.2

High compute, application workloads

A high compute, application workload will be a production environment with significant traffic and low latency.

Here, we’ll use a variable workload, with 8 vCPUs used during working hours (180 hours / month) and 2 /vCPUs during off-peak hours (550 hours / month). We’ll assume 5 instances/projects. In this scenario, there is no idle time.

With the Scale tier on Neon, this works out as:

(8 CUs *180) + (2 CUs * 550) * 5 Projects = 6,940 CU-hours

We have 750 CU-hours included in the Scale tier, so the cost for this would be:

$69 + (6,190 * $0.16) = $1,059.4

In Aurora Serverless:

(16 ACUs * 180) + (4 ACUs * 550) * 5 Instances = 25,400 ACU-hours

And the monthly price:

25,400 ACU-hours * $0.16 = $4,064

Conclusion

Both Amazon Aurora and Neon offer serverless options to run managed Postgres instances. While Aurora provides robust scalability and a rich set of features, Neon stands out with some advantages, mainly the capacity to scale to zero and a simpler and more transparent pricing structure with a free tier. This makes it a more attractive choice for startups and mid-sized businesses.