DEV Community: Hackmamba

The 11 best AI code editors in 2026

Obisike Treasure — Mon, 20 Apr 2026 20:00:56 +0000

Code editors remain the foundation of modern software development—the place where developer experience (DevX) is shaped and ideas turn into production-ready code. As AI continues to reshape how developers work, AI code editors have become an essential part of the development workflow.

In 2026, the biggest shift is the deep integration of AI directly into code editors. Today’s best AI code editors go far beyond basic autocomplete, offering intelligent code suggestions, early bug detection, automated refactoring, and real-time explanations of complex logic. These capabilities can dramatically improve productivity—but they also make choosing the right AI code editor more challenging as the market becomes increasingly crowded.

Many tools promise to “write your entire app for you” or claim you’ll “never debug again.” In reality, only a small number of AI-powered code editors consistently help developers ship cleaner, more reliable code faster—without relying on exaggerated marketing claims.

This guide cuts through the noise to highlight the ten best AI code editors in 2026, focusing on real-world performance, workflow fit, and long-term value. Whether you’re a solo developer or part of a large engineering team, this list will help you find the AI code editor that best matches how you actually build software.

What makes a great AI code editor?

The best AI code editors do more than toss you a few autocomplete suggestions. They’re like a reliable teammate who knows your codebase, catches your mistakes before you do, and helps you ship cleaner, faster.

A great AI-powered code editor usually ticks a few key boxes:

Smart code suggestions: Auto complete/code completion that is not just syntax-aware but also understands the intent behind your code, offering solutions that actually make sense for your project.
Bug detection & static analysis: Automatically flags errors, potential bugs, and security vulnerabilities before they become production headaches.
Refactoring assistance: Restructure messy code or optimize performance with just a few prompts.
Seamless integration: Fits neatly into your workflow, working with your existing tools from Git and CI/CD (continuous integration and continuous deployment) pipelines to testing frameworks and API explorers.
Context awareness: Reads and understands your project, understands dependencies, and adapts its suggestions accordingly.
Multi-language code generation support: Handles multiple programming languages as well as generate code without losing accuracy or speed.
Conversational code comprehension: Understand and explain your complex code on request. Whether it’s walking through a feature, breaking down complex logic, tracing dependencies, or finding where a function is used, the AI can adapt its explanations to your skill level, like having a patient senior developer always on hand.

Types of AI code editors

Now that you know what makes a great AI code editor, it’s worth noting that not all of them are built for the same purpose. Some excel at writing and refactoring, others focus on debugging or security, and some are designed to help you better understand your codebase. Choosing the right one starts with understanding which type best fits your needs.

IDE-native assistants

These plug directly into existing editors like VS Code or JetBrains IDEs. GitHub Copilot is the most well-known example, offering real-time code suggestions and completions without forcing you to switch environments.

AI-first editors

Tools like Cursor are built from the ground up with AI at their core. Instead of bolting features onto an existing IDE, they reimagine the coding workflow with chat-driven refactoring, context-aware search, and deeper code understanding.

Cloud and browser-based environments

Platforms like Replit embed AI agents into fully online coding workspaces. They prioritize accessibility, instant collaboration, and the ability to spin up projects without heavy local setup.

Team centric and autonomous agents

Editors such as Tabnine and Sourcegraph Cody focus on scaling AI help across teams. They emphasize codebase-wide context, knowledge sharing, and integration into CI/CD pipelines, making them ideal for collaborative or enterprise use cases.

Evaluating the 11 best AI code editors in 2026

With the categories in mind, here are some of the best AI code editors in 2026, along with what they do best, where they shine, and what to watch out for.

Editor's Note: All statistics in this article were verified at the time of publication in January 2026. Please be aware that product information is subject to change in the months following.

1. Cursor

Cursor is essentially VS Code rebuilt from the ground up with AI integration in mind. Unlike other editors that bolt on AI features, Cursor's entire interface revolves around AI assistance. Cursor's homepage describes it as "the best way to code with AI, built to make you productive." How well it delivers on that promise will depend on your coding style and how much budget you’re willing to allocate.

Ben Bernard at Instacart reports that Cursor delivers a 2x improvement over Copilot. Kevin Whinnery, from OpenAI, notes that around 25% of tab completions anticipated exactly what he wanted to write. However, these testimonials come primarily from users at well-funded tech companies that can afford the premium pricing.

Cursor ranks around the top 10 most used editors, according to the Stack Overflow survey.

Here are some of the features and benefits that make Cursor stand out:

Tab completion with deep context: Analyzes your entire project, not just the current file.
Natural language editing: You can literally tell it "refactor this function to use async/await."
Agent Mode: Can autonomously handle multi-file changes and dependency management.
Codebase chat: Ask questions about your entire project structure.
Privacy controls: Optional mode where code never leaves your machine.
VS Code compatibility: Imports your existing setup with one click.

Some of the downsides of using Cursor may include: cost, usage limits, being too heavy for older computers or large codebases, and a learning curve when transitioning to the editor.

2. GitHub Copilot (with VS Code)

GitHub Copilot is the "Toyota Camry" of AI coding assistants - reliable, widely supported, and unlikely to surprise you. Originally powered by OpenAI's Codex, by 2026 it has gotten upgrades with GPT-5o, Claude Opus 4.5 and other frontier models. It's the obvious choice if you're already in the GitHub ecosystem.

According to a GitHub blog post from February 2023, when Copilot for Individuals first launched in June 2022, more than 27% of developers’ code files were generated by the tool. By that report, Copilot had scaled to generating approximately 46% of all code produced by developers, and reached a high of 61% in Java.

Some of the features of Copilot include:

Universal compatibility: Works in virtually every editor you already use.
Multiple AI models: Can switch between different providers (GPT, Claude, Gemini).
GitHub integration: Seamlessly works with your existing workflow.
Mature ecosystem: Extensive documentation and community support.
Enterprise features: Good compliance and security controls for large organizations.

It might seem good, but here are some of its downsides:

Limited codebase understanding.
Your code goes to Microsoft's servers by default, which may introduce privacy issues.
Generic suggestions and inconsistent quality.

3. Windsurf

Windsurf positions itself as "the world's most advanced AI coding assistant" - a bold claim for a relatively new player. Built by the Codeium team, it's trying to out-execute both Cursor and Copilot with a focus on speed and user experience.

According to a reddit user, windsurf really gets context and can pull off insane edits. Since its inception, windsurf has seen a significant increase in its adoption boasting of about one million downloads by February 2024.

Some of its features include:

Cascade AI agent: Can work autonomously on complex, multi-step tasks.
Dual modes: Separate chat and write modes to avoid context confusion.
Fast performance: Noticeably quicker responses than competitors.
Real-time collaboration: Built-in pair programming features.
Generous free tier: More usable than most competitors' free options.

As promising as Windsurf might be, it has issues like feature instability due to the fact that it's fairly new. Its ecosystem is limited as it has fewer integrations and community resources and lastly its documentation is still in the works.

4. Xcode AI Assistant

Released at WWDC 2025, it integrates ChatGPT, Claude, and other AI models directly into Xcode. However, it requires macOS 26 Tahoe and feels like Apple playing catch-up rather than leading innovation. This is still in the Beta version and it needs a paid developer account.

Its known features include:

Multi-model support: Can switch between ChatGPT, Claude, Gemini, and local models.
No account required: Use ChatGPT's free tier without registration (with daily limits).
API key flexibility: Bring your own API keys from multiple providers.
Local model support: Run Ollama or LM Studio models directly on Apple Silicon.
Swift-optimized: On-device model specifically trained for Swift and Apple SDKs.
Coding Tools integration: AI assistance directly in the source editor.
Privacy focused: Code never stored on servers, not used for training.

Its downsides include beta limitations, daily rate limits and Apple ecosystem lock-in.

5. Replit Ghostwriter

Replit is a cloud-based IDE with AI features called Ghostwriter. It's designed for real-time collaborative coding in a browser-based environment, making it ideal for education, prototyping, and getting started quickly.

Replit is known to be trusted by founders and Fortune 500, one of which is Allfly whom stated that they rebuilt their app in days, saving $400,000+ in development costs with 85% productivity increase. There are several other testimonies but most advertise it as a very good vibe coding tool.

Here are some of its features:

Zero setup: Start coding immediately in any browser.
Educational focus: Excellent for learning new languages or concepts.
Real-time collaboration: Multiple people can code together seamlessly.
Proactive debugging: Automatically detects and suggests fixes for errors.
Full program generation: Can create entire applications and generate code from descriptions.

The downsides of using Ghostwriter includes:

It cant be used outside Replit.
It's highly internet-dependent as it uses the browser.
It has some performance constraints and limited scalability as it doesn't do well with very large or complex applications development.

6. JetBrains AI Assistant

JetBrains AI Assistant is built specifically for IntelliJ IDEA, PyCharm, WebStorm, and other JetBrains IDEs. It leverages JetBrains' existing code analysis capabilities but requires you to already be invested in their ecosystem.

According to a reddit user, it is taking a turn for the better. Although most users mentioned that it started out badly, there is recent feedback of it being good.

It has a couple of features you might find interesting.

Native integration: Seamlessly works within the familiar JetBrains interface.
Advanced code analysis: Leverages JetBrains' existing static analysis tools.
Refactoring assistance: Intelligent suggestions for code improvement.
Testing support: Automated test generation within the IDE workflow.
Documentation generation: Automatic creation of code documentation.

Some of its downsides are that;

Vendor lock-in*:* Dependence on the JetBrains ecosystem is a potential drawback.
Scope limitations: The tool's functionality is confined to a restricted area.

7. Amazon Q Developer + VSCode

Amazon Q Developer is Amazon's AI-powered coding assistant that evolved from CodeWhisperer. It's specifically optimized for AWS development and cloud-native applications, making it the go-to choice for teams building on Amazon's cloud infrastructure.

Amazon Q Developer is trusted by enterprise teams, with companies like Ancileo reporting 30% faster environment setup, 48% increase in unit test coverage, and 60% of developers focusing on more satisfying work. The tool excels at understanding AWS services and helping developers build cloud-native applications with best practices built in.

Here are some of its features:

AWS integration: Deep understanding of AWS services, CloudFormation, CDK, and cloud architecture patterns.
Security-focused: Built-in vulnerability detection and AWS security best practices enforcement.
Code transformation: Helps modernize legacy applications for cloud deployment.
Multi-IDE support: Works seamlessly with VS Code, JetBrains IDEs, and directly in AWS Console.
Infrastructure as code: Specialized support for CloudFormation, CDK, and Terraform.
Generous free tier: More free usage compared to most competitors.

The downsides of using Amazon Q Developer include:

AWS bias: Primarily useful for AWS development, less helpful for other cloud platforms or non-cloud projects.
Limited general coding: Weaker at generic programming tasks compared to general-purpose AI assistants.
Vendor lock-in: Ties you deeper into Amazon's ecosystem and services.
Enterprise focus: Features and pricing are geared toward teams rather than individual developers.

8. Trae

Trae (The Real AI Engineer) comes from ByteDance, the company behind TikTok, which should immediately raise privacy red flags. It's positioned as a completely free AI IDE built on VS Code, offering Claude 4.5 Sonnet and GPT-5o integration. Recently, it has support for Grok. It usually produces more accurate first attempts compared to editors like Cursor due to its "think-before-doing" approach. But it comes at the cost of speed.

Some of its key features include:

Completely free: All AI features available without subscription costs.
High-end model: Access to Claude 4.5 Sonnet and GPT-5o at no cost.
Builder Model: Plans before executing changes for better accuracy.
Comment-driven generation: Write what you want in comments, and AI implements it.
Multi-modal chat: Supports images for visual context and debugging.
VS Code foundation: Familiar interface with extension support.
Cross-platform: Available on macOS and Windows (Linux planned).

One of its major downsides is privacy. ByteDance's data collection practices raise serious privacy questions. And also, it's a fairly newer platform which might not be as mature as the others.

9. Bolt.new

Bolt.new by StackBlitz represents a different approach - it's not a traditional code editor but an AI-powered web app builder. You describe what you want, and it creates a full-stack application running in the browser. With over 1 million websites deployed in five months, it's proven the concept works for rapid prototyping.

Some key features include:

Browser-based development: No local setup required, everything runs in WebContainers.
Full-stack generation: Creates complete applications with frontend and backend.
Framework flexibility: Supports React, Next.js, Vue, Svelte, Astro, and more.
NPM package support: Can install and use third-party libraries.
One-click deployment: Built-in hosting on bolt.host domains.
GitHub integration: Sync projects for version control and collaboration.
Live preview: See changes instantly as the AI builds your app.

Its downsides are:

Token consumption: Can burn through credits quickly, especially with mistakes.
Fix-and-break cycle: AI often creates new problems while solving existing ones.
Limited to JavaScript: Only supports web technologies, not native apps.
Complexity ceiling: Struggles with very complex business logic.
Debugging frustration: Hard to troubleshoot when AI-generated code fails.

10. Zed

Zed is the anti-Electron editor - built from scratch in Rust by the creators of Atom, it promises blazing-fast performance and native responsiveness. While it delivers on speed, it's still catching up on features and stability. Think of it as the sports car of code editors: incredibly fast when it works, but you might need a backup for reliability.

Key features and benefits:

Rust-powered performance: Genuinely fast startup, file handling, and UI responsiveness.
Native multiplayer collaboration: Real-time coding with teammates built into the core.
Agentic AI editing: AI can make autonomous code changes across files.
Open source: Full GPL v3 license with active community development.
GPU acceleration: Uses custom shaders for rendering performance.
Multiple AI model support: Supports Claude, OpenAI, local models via Ollama.
Edit predictions: AI anticipates your next moves (when it works).

Downsides:

Stability issues: Users report frequent crashes, CPU spikes, and buggy behavior.
Limited extension ecosystem: Tiny selection compared to VS Code's thousands.
Missing core features: No integrated debugger, limited language support.
Python experience is poor: LSP integration problems make it frustrating for Python devs.
Windows support lacking: No stable Windows release yet (building from source only).
Early development stage: Many basic IDE features are still missing or broken.

11. PearAI

PearAI is an open-source AI code editor that's a fork of VS Code with integrated AI tools. It's designed to supercharge development by seamlessly integrating a curated selection of AI tools into a familiar VS Code interface, making AI-powered coding more accessible.

PearAI has gained attention from Y Combinator backing and claims from users like a Meta DevX engineer who said it helped them go from "complete noob to Senior Engineer productivity in Swift iOS in less than a month." However, the project has also faced controversy over licensing issues when it initially tried to apply a proprietary license to open-source code.

Here are some of its features:

Familiar VS Code interface: Built as a fork of VS Code, so existing users can transition seamlessly.
Codebase context awareness: AI understands your entire project for more relevant suggestions and code generation.
Integrated AI tools: Combines multiple AI coding tools (Continue, Supermaven, etc.) in one unified interface.
Inline AI editing: Direct code modification with CMD+I (CTRL+I) to see diffs and make changes.
Multi-model support: Access to various AI models through PearAI Router for optimal coding performance.
Zero data retention: Privacy-focused with local code indexing and no data collection.

The downsides of using PearAI include:

Licensing controversy: Initially faced criticism for attempting to apply a proprietary license to open-source code.
Limited differentiation: Essentially combines existing tools (VS Code + Continue) rather than creating novel features.
Early stage development: Still developing unique features beyond what's available in the original tools it forks.

Tips for choosing the best AI coding editor

When choosing an AI code editor, consider the factors below to ensure it aligns with your coding requirements and preferred workflow.

Evaluate your privacy and security requirements first

Before getting dazzled by AI features, honestly assess your data sensitivity. If you're working with proprietary code, client data, or in regulated industries, tools that send your code to third-party servers might be non-starters regardless of how impressive their AI capabilities are. Consider whether you need an on-premises deployment, local model hosting, or can accept cloud-based processing with appropriate security certifications.

Match the tool to your actual development workflow

Don't choose based on demo videos or marketing promises. Consider your real daily tasks: Are you primarily coding solo or collaborating? Do you spend more time writing new code or maintaining existing systems? Are you building simple scripts or complex enterprise applications? The most feature-rich AI editor won't help if it doesn't integrate well with your existing tools, version control systems, and deployment pipelines.

Start small and test with real projects

Most AI coding tools offer free tiers or trials - use them properly. Don't just test with toy examples; try them on actual projects you're working on. Pay attention to how the AI performs with your specific programming languages, frameworks, and coding patterns. What works brilliantly for web development might be frustrating for data science or mobile development.

Consider the total cost of ownership, not just subscription fees

Look beyond monthly subscription costs. Factor in the time needed to learn new tools, migrate existing setups, train team members, and potentially vendor lock-in. A "free" tool that requires weeks of configuration might be more expensive than a paid solution that works immediately. Similarly, cheap tools with usage limits might become expensive as your team grows or your projects become more complex.

Plan for change and avoid over-dependence

The AI coding landscape is evolving rapidly. Choose tools that give you flexibility to switch models, export your work, or migrate to alternatives if needed. Be particularly wary of platforms that make it difficult to access your code or that use proprietary formats. The best tool today might not be the best tool next year, so maintain some degree of vendor independence.

The future of AI code editors

The proliferation of AI coding editors, from enhanced classic editors to revolutionary application builders, offers developers many options, each with trade-offs in power, cost, and control.

No single “best" AI coding editor exists; the ideal choice depends entirely on specific requirements, limitations, and preferences (e.g., a large enterprise versus a solo developer).

Ignore hype and trends. Focus instead on defining your genuine needs and rigorously testing tools against real-world scenarios. The most effective AI coding editor is the one that boosts your team's productivity and aligns with your practical constraints.

The ultimate goal is consistently to deliver superior software more quickly. Therefore, select your tools based on how well they support this objective.

What if ML pipelines had a lock file?

Offisong Emmanuel — Wed, 11 Feb 2026 16:16:24 +0000

I spent two hours last month staring at identical Git commits trying to figure out why my model retrain had different results.

The code was the same. The hyperparameters were the same. I was even running on the same machine. But the validation metrics had shifted by 12%, and I couldn't explain why. I checked everything twice: my random seeds were fixed, my dependencies were pinned, my Docker image hadn't changed. Then I looked at the data.

Someone had added a column to an upstream table and backfilled it. Nothing broke. The pipeline kept running. Training succeeded. But the feature distribution had shifted, and the model had learned from data that no one realized was different.

That experience changed how I think about ML pipelines. We can lock dependencies. We can lock infrastructure. But the computation itself has no identity. Pipelines are still scripts that read mutable data, assume schemas that drift, and depend on execution details that change quietly.

In this article, we’ll walk through why that makes ML pipelines hard to reproduce, what a pipeline lock file actually needs to capture, and how treating computation as an artifact changes how we debug, audit, and build models.

Why ML pipelines are hard to reproduce

When an ML pipeline fails to reproduce, the code is rarely the problem. Most teams already version their training scripts, feature logic, and model code using Git. The issue is that the meaning of that code depends on far more than what lives in the repository.

Consider a fraud detection pipeline use-case. The code reads transaction data, joins it with user profiles, applies feature transformations, and trains a model. The Python script and SQL queries are tracked in Git. The model architecture is documented. Everything looks reproducible.

After a while, fraud detection accuracy drops in production, and you are tasked to recreate the training run for an audit, but you can't. The code runs, but the model comes out different. Something changed, but what?

The problem is that ML pipelines don't just depend on code. They depend on data, schemas, and execution details that live outside the repository and change without anyone noticing.

Data
Pipelines usually read from tables that change over time. Most of these tables are stored in a data warehouse like Amazon Redshift or Google BigQuery. Rows are added or removed. Backfills happen. A column gets renamed or its meaning changes. Even when teams snapshot data, those snapshots are often implicit, not recorded as part of the pipeline run itself.

In this fraud pipeline, training data comes from a warehouse table like transactions. Between the original training run and the reproduction attempt, the data team backfilled several months of historical records to fix a reporting bug. The pipeline query didn’t change:

SELECT * FROM transactions WHERE date >= '2025-01-01'

But the rows returned did.

The original model was trained on one set of data (transaction amounts, merchant categories, and user behavior), while the reproduced run was trained on a different set. Even though both runs used the same code, neither recorded which specific data version was used.

From the outside, it looks like “the same pipeline.” In reality, two different datasets flowed through it.

The problem is even worse with derived tables. If the fraud model depends on a shared feature table maintained by another team, and that team fixes a bug in their aggregation logic and recomputes the table, our pipeline can keep running and silently consume the updated features. There is no error or warning, just different inputs flowing into the same code.

Schemas
Schemas add another layer of fragility. Many pipelines assume schemas rather than enforce them.
During the fraud detection data backfill, the schema changed, too. A new column, merchant_risk_score, was added to the transactions table. It was nullable at first because historical data didn’t have values for it yet.

The feature pipeline didn’t break. It simply treated missing values as zero during normalization. That meant older transactions effectively had no merchant risk, while newer ones suddenly did. The feature still existed. The code still ran. But the meaning of the feature changed.

As a result, the model learned two different behaviors depending on when a transaction occurred. Recent data emphasized merchant risk. Older data didn’t. Overall metrics looked fine during training, but once deployed, the model began misclassifying edge cases in production.

When accuracy dropped, the team assumed normal data drift and retrained. The retrain succeeded, but the new model still didn’t match the original. The schema change had rewritten the semantics of the features, and nothing in the pipeline recorded that shift or made it visible.

Dependencies and execution details
Dependencies and execution details add another layer of instability. A query planner may choose a different plan. A caching layer may reuse an old result. A User Defined Function (UDF) can change behavior because one of its dependencies was updated. None of this shows up in git, and very little of it is visible in logs.

Caching sometimes alters your model performance. They speed things up, which is good. But they also introduce a hidden state that can change results between runs. For example, your pipeline caches a feature table. Someone updates the upstream logic. Your cache is now stale, but nothing tells you that. You're training on a mix of old features and new data.

Even the runtime version matters. The original model artifact had been serialized with Python 3.9, but the reproduction ran under Python 3.11. The model loaded successfully, but downstream behavior wasn’t identical.

The result
The pipeline was reproducible in theory, but not in practice. The same code ran. A different computation happened.

There was no single artifact to inspect. No receipt that captured the data that was read, the schemas that were assumed, the UDF logic that executed, or the cache state that influenced the result. The team spent weeks reconstructing the run from logs, guesses, and tribal knowledge.

This is the gap lock files solved for software dependencies. And it’s the same gap ML pipelines still have today.

Why existing tools don’t fix this

At this point, most teams reach for familiar fixes.

They add more logging. They version datasets manually. They pin library versions. They introduce orchestrators, lineage tools, and experiment trackers. Each tool helps in isolation, but none of them answer the one question that matters during an incident or an audit:

What actually ran?
Logs tell you that a job executed, not which data it read. Git tells you what the code looked like, not how it resolved at runtime. Lineage graphs show connections, but not the concrete inputs, schemas, or cached state used in a specific run. Experiment tracking stores metrics and artifacts, but not the computation that produced them. So when something goes wrong, teams are left reconstructing history from fragments and guesswork.

The deeper issue is that ML pipelines don’t produce a durable artifact of the computation itself. The code is versioned, but the resolved execution is not. Data is mutable. Schemas drift. Execution details change. And none of that has a stable identity you can point to later.

Software engineering solved this problem years ago. We didn’t fix reproducibility by writing better README files or adding more logs. We fixed it by introducing lock files. Lock files are machine-readable artifacts that capture the fully resolved state of a system at execution time, representing the actual thing that ran rather than configuration.

The missing piece in ML is the same idea, applied to computation.

What an ML pipeline lock file actually is

An ML pipeline lock file is not a configuration file. It is not another place to declare what you want to run. It is a record of what actually ran.

In software, a lock file answers a simple question: What was installed? Not which dependencies were requested, but which ones were resolved, down to exact versions and hashes. An ML pipeline lock file needs to answer the same kind of question, but for computation. What computation is this?

That requires three things:

An explicit computation graph
Content identities
Roundtrippability

An explicit computation graph
The lock file must capture the computation as a concrete object. Not a Python script that does things, but the actual reads, transformations, joins, aggregations, UDFs, and caches that make up the pipeline.

For example, when you look at package-lock.json, you don't see installation scripts. You see the resolved dependency tree. Each package, each version. The lock file for an ML pipeline needs the same clarity.

Content identities
Every piece of the computation needs an identity based on its content. The inputs you read. The UDFs you execute. The dependencies you use. The cached artifacts you produce. Same inputs should mean the same identity and different inputs should mean different identities.

If two runs have the same content identities for their inputs, UDFs, and dependencies, they're running the same computation. If any of those identities differ, something changed. You don't have to guess. You can check the hashes.

Roundtrippability
One of the core features of an ML lock file is roundtrippability. A real pipeline lock file must be runnable on its own. Given the lock file and its associated artifacts, you should be able to rerun the pipeline without relying on a particular machine, environment, or set of hidden caches.

If your lock files have these features, you can diff computations the way you diff lock files. You can verify that a rerun is actually running the same thing. You can cache based on content, not guesses. You can bisect regressions by comparing hashes instead of reading through logs.

Git vs. Manifests

A useful way to understand the value of manifests is to compare what traditional version control captures with what a build manifest records. Git excels at tracking how a pipeline is written, but it stops short of describing the fully resolved computation that actually executed. The manifest (expr.yaml) fills in that missing layer by freezing the execution-time reality of the pipeline.

	Code (git)	Manifest (expr.yaml)
Pipeline definition	✓	✓
Resolved inputs at execution time	✗	✓
Schema contracts	✗	✓
UDF and UDXF content hashes	✗	✓
Cached artifacts	✗	✓
What actually ran	✗	✓

Git is excellent at tracking the source code that defines a pipeline. The manifest goes further by recording the resolved state of that pipeline at execution time.

Create an ML lock file using Xorq

Once you understand what a pipeline lock file is and why it matters, the next step is seeing it in action. Xorq makes it straightforward to turn a declarative pipeline into a reproducible, versioned artifact with a lock file.

To get started, install Xorq using pip or uv:

pip install "xorq[examples]"

uv add "xorq[examples]"

Next, download the financial fraud dataset from Kaggle and place the CSV file in your working directory. This example uses a simplified fraud detection pipeline, but the structure mirrors what you would build in a real production system.

Create a file main.py with the following content:

import xorq.api as xo
from sklearn.ensemble import RandomForestClassifier
from sklearn.pipeline import Pipeline
from xorq.caching import ParquetCache
from xorq.config import options
import os
# specifies cache directory as current directory/cache
options.cache.default_relative_path=f"{os.getcwd()}/cache"
con = xo.connect()
cache = ParquetCache.from_kwargs()
# 1. Load the dataset
data = xo.read_csv('synthetic_fraud_dataset.csv')
# 2. Train / test split
train, test = xo.train_test_splits(data, test_sizes=0.2)
sk_pipeline = Pipeline([
    ("model", RandomForestClassifier(
        n_estimators=200,
        max_depth=10,
        random_state=42
    ))
])
# 3. Define the model
model = xo.Pipeline.from_instance(sk_pipeline)
# 4. Fit the model
fitted = model.fit(
    train,
    features=[
        'amount',
        'hour',
        'device_risk_score',
        'ip_risk_score'
    ],
    target='is_fraud'
)
# 5. Generate predictions (deferred execution)
predictions = fitted.predict(test).cache(cache=cache)
# 6. Execute the computation
print(predictions.execute())

A few important things are happening here. The entire pipeline is defined declaratively, with each step clearly described: data ingestion, train–test splitting, model configuration, and a cached prediction stage. Nothing runs until execution is requested. When it does run, Xorq has enough information to capture the full computation as an explicit graph.

At this point, you have a working ML pipeline. In the next step, instead of just running it, we will build it. That build step is what produces the lock file: a manifest that records the resolved computation, the data it read, the schemas it assumed, the cached artifacts it created, and the exact logic that ran.

If your project directory is not already a Git repository, you need to initialize one before building an expression. Xorq records the git state as part of the build metadata, so a repository with at least one commit is required.

Run the following commands in your project folder:

git init
git add .
git commit -m "initial commit"

Once the repository is initialized, you can build the expression and generate the lock file by running:

xorq build main.py -e predictions

If you are using uv, the equivalent command is:

uv run xorq build main.py -e predictions

This build step is what turns your pipeline from a runnable script into a versioned artifact, complete with a manifest that records the resolved computation.

The output of the run is shown in the image below:

After the build completes, you should see two new directories: builds and cache. The cache directory holds cached intermediate results created during execution. The builds directory contains the build artifacts themselves. Inside builds, you will find a directory named with a content derived hash, for example 78ff43314468. This directory is the lock file in practice. It is the concrete, portable representation of the pipeline run.

Within that directory, several files are generated automatically, including expr.yaml, metadata.json, and profiles.yaml. The most important of these is expr.yaml. This file is the receipt for what actually ran. It describes the computation graph, the resolved inputs, the schema contracts, the cached nodes, and the content hashes that give the pipeline its identity.

Taken together, the build directory is a versioned, cached, and portable artifact. Once it exists, workflows that were previously fragile or manual become straightforward: reproducible runs, diffable computation, bisectable regressions, portable artifacts, and, importantly, composition.

The expression file
At first glance, expr.yaml looks intimidating. It contains many components, but its purpose is simple. It describes the computation itself, explicitly and completely.

Below is an abridged example:

nodes:
    '@read_4d6c147c9486':
      op: Read
      method_name: read_parquet
      name: ibis_read_csv_nepinfk5dzbxja2bo4kycwisyq
      profile: 846181d9920579c7c1b10dd45b3ab9b2_0
      read_kwargs:
      - - path
        - builds/78ff43314468/database_tables/917eccee9a442913a8c1afca12cf69b0.parquet
      - - table_name
        - ibis_read_csv_nepinfk5dzbxja2bo4kycwisyq
      normalize_method: fvfvfvfvf
      schema_ref: schema_c4a0925bdfca
      snapshot_hash: 4d6c147c9486fe2f5140558ff6860b60

This first node answers a deceptively important question: What data was read? Not “which table name,” and not “which query,” but the exact data source. The Read node points to a concrete file, often materialized into the build directory itself. That means the pipeline is tied to the data that was actually used, not whatever that table happens to contain today.

The schema_ref is part of the plan. If the schema changes, this node no longer matches, and the computation’s identity changes with it.

Now look at how transformations are represented:

    '@filter_d5f72ffce15d':
      op: Filter
      parent:
        node_ref: '@read_4d6c147c9486'
      predicates:
      - op: LessEqual
        left:
          op: Multiply
          left:
            op: Cast
     predicted:
          op: ExprScalarUDF
          class_name: _predicted_18c1451165c

The code above describes the filter. The predicate itself is part of the graph, not hidden inside a function call or a SQL string. The filter is explicitly connected to its parent node, so there is no ambiguity about ordering or dependencies.

Every transformation builds on a previous node, forming a complete expression tree:
Read → Filter → Aggregate → Cache

Later in the file, you’ll see nodes like this:

'@cachednode_e7b5fd7cd0a9':
  op: CachedNode
  parent:
    node_ref: '@remotetable_9a92039564d4'
  cache:
    type: ParquetCache

Caching is also part of the computation. Because the cache appears in the graph, it is reproducible and portable. There are no hidden cache keys, no local assumptions, and no silent reuse of stale results. If the upstream logic changes, the cache node’s identity changes too.

Finally, notice the node names themselves:

@read_4d6c147c9486
@filter_d5f72ffce15d
@cachednode_e7b5fd7cd0a9

These identifiers are content-derived. They are hashes of the node’s inputs, logic, schema, and configuration. Change anything meaningful, and the identifier changes. That change propagates through the graph.

This is what makes expr.yaml a lock file. Instead of saying “run this Python script,” it records what computation resolved, what data it read, what schemas it assumed, and where caching occurred. The hash of the build becomes the identity of the computation itself.

Treating pipelines as building blocks

So far, we’ve looked at how Xorq turns a pipeline into a versioned artifact. The payoff comes because these artifacts are composable. When you build a pipeline with Xorq, the output isn’t just a model or a metric. It’s a versioned computation artifact with a stable hash e.g. xyz123. That hash represents the fully resolved training run: data, schemas, feature logic, and execution details.

Because that artifact has an identity, it can be reused. An inference pipeline can explicitly reference the training artifact it depends on. Instead of “load the latest model,” it loads the model produced by build *xyz123*, along with the exact feature definitions and schema contracts that training used. If training changes, inference doesn’t silently drift. The composition produces a new hash.

This also makes deployment seamless. You can easily rollback to previous hashes without guesswork.

Why is this different from experiment tracking?
Tools like MLflow track artifacts. DVC versions data. Both are useful but neither gives you composable, versioned computation graphs.

MLflow can tell you which model file was produced, but not the resolved computation that created it.
DVC can version datasets, but not how those datasets were transformed, joined, cached, and consumed end-to-end.

Xorq’s unit of composition is the computation itself. Training pipelines produce artifacts that inference pipelines can depend on directly, without re-encoding assumptions in glue code.

What do we gain from this?

The most immediate gain is reproducibility. With a pipeline lock file, rerunning a pipeline means rerunning the same computation, not just the same code. The inputs are fixed, the schemas are known, the logic is explicit, and cached artifacts are part of the record. “Works on my machine” stops being a concern because the computation has a concrete identity.

You can easily run builds by:

xorq run builds/<build-hash>

Another advantage is portability. This means you can take a build produced on a developer’s laptop and execute it in CI, inside a container, or on a different execution engine with confidence that it will behave the same way.

Also, when a model regresses, you can diff runs. Two builds produce two manifests. Instead of guessing what changed, you get a semantic diff: data sources, schema changes, UDF content, planner decisions, cached nodes. This turns multi-week investigations into focused comparisons.

Schema drift becomes visible early. Because schemas are part of the contract, drift shows up at boundaries rather than leaking silently into downstream logic. Pipelines fail fast, in the right place, instead of producing subtly wrong models.

Finally, there is an organizational gain. When computation is explicit and versioned, teams move faster with less risk. Audits become tractable because training runs are reproducible.

Closing insights

Lock files changed how we think about software. They gave us a stable unit we could diff, ship, and trust. ML pipelines have needed the same thing for a long time, but until now, there has been nothing concrete to lock.

By giving computation an identity, pipeline manifests turn runs into artifacts. They capture what actually ran, not just what the code described. Once that exists, reproducibility, debugging, audits, and collaboration stop being fragile processes and start becoming mechanical.

Xorq provides a practical and robust foundation for building reproducible, auditable, and production-grade ML workflows. This makes it easy to generate an ML lock file that captures not just what was written, but what actually ran, including resolved inputs, content hashes, and cached artifacts.

For more information about Xorq, head over to their GitHub or their official documentation.

Which Technical Content Marketing Agency Should You Work With in 2026?

Mohammed Tahir — Thu, 29 Jan 2026 09:21:40 +0000

Finding the right technical content marketing agency can be harder than it might actually look.

Most technical content today is written by AI. But useful technical content still comes from understanding how the product actually works.
You know you need technical content marketing. The challenge is finding a content marketing agency that understands both technology and how to market to developers.

Along with writers who can explain OAuth flows, you need strategists who know developer channels, SEO for technical audiences, content distribution, and how to turn documentation into a growth lever.

That’s why different agencies exist. Some specialize in developer-focused content marketing because reaching developers requires different expertise than targeting enterprise buyers. Others focus on high-volume content and organic traffic because growth-stage companies need a consistent SEO strategy. A few concentrate on technical documentation as part of their content marketing program.

Pick the wrong agency, and you'll waste months and thousands of dollars. An enterprise-focused agency often struggles to understand developer audiences. A volume-focused agency will sacrifice the depth technical buyers need. A generalist will compromise the details that make technical content credible.

This breakdown shows you which agencies excel at what, so you can match your needs to their strengths instead of wasting time on partnerships that won't work.

## TL;DR

Company	Primary Focus
Hackmamba	Full-suite developer marketing (written + video content, technical documentation, SEO, distribution)
DevSpotlight	Enterprise technical content for developers
Literally	Technical documentation and knowledge management
Velocity Partners	Enterprise B2B SaaS content and positioning
Animalz	High-volume content for growth-stage SaaS
Twogether	Full-service B2B technology marketing
Foundation	Content strategy and distribution for B2B SaaS
Siege Media	SEO-driven content at scale
nDash	Freelance technical writer marketplace
The Rubicon Agency	Cybersecurity, SaaS, Cloud & AI

## What Makes a Great Technical Content Marketing Agency?

1. Technical credibility paired with marketing expertise. Writers need to understand your product deeply enough to explain it accurately while making it compelling and engaging. This balance is rare.

2. SEO strategy built for developers. Developers look for solutions and not just products. They used discussion forums like Stack Overflow and now AI, before Google. They trust peers over marketing pages. Your agency needs to get this.

3. Ability to scale without losing quality. Can they handle launch campaigns, tutorials, case studies, and ongoing blog content simultaneously without compromising on depth?

4. Distribution and amplification. Getting content in front of the right people is challenging. The best agencies have well-planned distribution strategies, community partnerships, strong developer relations, and strategic placement.

5. Decision-making criteria:

Writers with technical backgrounds.
Proven SEO results in your desired domain.
Clear process for strategy, feedback, and iteration.
Case studies with measurable outcomes.
Transparent pricing and engagement models.

Dimension	What great looks like	How to evaluate when talking to an agency	Red flags
Technical credibility	Writers with engineering experience or proven hands-on product work. Content includes runnable examples, configuration files, benchmarking notes, and known limitations.	Ask for writer bios, links to technical repos they authored, and sample pieces containing code you can run. Request a short technical exercise or review of your API doc to see how they handle nuance.	Writers without public engineering work or writers who avoid technical reviewers.
Developer-focused SEO	Keyword strategy built from problem queries and forum threads, not brand keywords only. Optimization for AI answer surfaces and search result features like snippets and knowledge panels.	Ask for evidence of ranking for problem queries, examples of optimizing content for community formats, and metrics showing AI or organic referral lifts. Request a content map tied to developer job-to-be-done queries.	Pure volume SEO promises with no sample developer keyword research or no plan for AI answer optimization.
Ability to scale without losing quality	Repeatable production process that preserves technical review steps. Workflow integrates product engineering, QA, and release notes. Content templates include code sandboxes, tests, or downloadable artifacts.	Ask for the agency editorial workflow, SLAs for technical review, headcount per content type, and sample multi-piece program (launch + docs + tutorials). Request audit of a 3-month content cadence.	One-size-fits-all content factories that omit engineering review and expect product teams to copy edit everything.
Distribution and amplification	Clear plan across community channels, DevRel, OSS touchpoints, newsletters, relevant subreddits, GitHub, and paid placements where appropriate. Partnerships with developer communities and platform owners.	Ask for a distribution playbook for developer audiences, examples of community placements, and owned channel performance. Request introductions to community partners or past campaign examples.	No distribution plan beyond posting to the blog and hoping for organic traffic.
Measurement and impact	KPIs aligned to developer journeys such as API trial activation, reproducible example usage, issue creation from docs, demo signups, and downstream retention.	Ask for case studies showing activation or retention lifts and the exact attribution models used. Request sample dashboards and proposed KPIs for your product.	Focus on vanity metrics alone such as blanket pageview targets or social likes.
Process and collaboration	Clear roles for strategy, editorial, technical review, and release coordination. Versioned content workflows that mirror product releases.	Request RACI, editorial calendar integration with product roadmap, and examples of change-control for docs.	Refusal to integrate with product teams or no change process for technical updates.
Commercial model and transparency	Pricing broken down by deliverable type including engineering time, code examples, and ongoing support. Pilot projects available.	Ask for line item pricing, pilot scope, and change order rules. Negotiate a pilot with measurable acceptance criteria.	Vague scopes, flat rates for “all content”, or refusal to run a pilot.

The Top Technical Marketing Agencies (2026 Edition)

Developer-Focused Agencies

1. Hackmamba

Hackmamba is a developer marketing agency that helps SaaS teams and devtools drive product growth and deliver better developer experiences. Run by engineers, developer advocates, and marketers, they handle all content marketing efforts in-house with no AI-generated content.

Why It Stands Out

They handle the full developer marketing spectrum: written content (blogs, tutorials, case studies), video content creation, technical documentation, SEO strategy, demand generation, and community-led distribution. Your docs feed into your SEO strategy. Your blog content supports product adoption. Everything works together as part of a comprehensive content marketing program.

The distribution angle is also to be considered here. Hackmamba runs a community of over 1500 top-notch technical writers (Hackmamba Creators), so content gets distributed through internal network. They’re also AI-native in the sense that they optimize for how LLMs surface content, which is presently very important as developers increasingly use AI tools to find solutions.

They offer developer marketing content created by software engineers, technical documentation that accelerates integration, video content for product demos and tutorials, and fractional content leadership for go-to-market strategy.

Best For

SaaS companies, DevTools, APIs, Web3 platforms, and fintech products building for developers. Product teams with documentation that doesn't keep pace with the product. Marketing teams needing a full-service content marketing agency without overburdening internal teams.

Notable Work

Hackmamba has partnered with teams, helping them with:

Launch developer marketing campaigns that convert into active users and generate leads.
Creating, auditing, restructuring, and migrating docs to deliver clear, maintainable experiences developers trust.
Scaling organic traffic through technical SEO and community-led distribution.
Producing video content for product launches, tutorials, and developer education

Why Choose Them

You need a content marketing agency that understands your product at a technical level, which means, engineers who can create engaging written and video content, strategists who know developer channels and SEO, and a team that handles distribution along with publishing. You want documentation developers trust and a content marketing strategy that drives measurable business growth.

2. Devspotlight

DevSpotlight creates technical blogs, whitepapers, eBooks, and tutorials for enterprise clients. They specialize in AI, DevOps, cloud, data, APIs, and blockchain content written by subject matter experts.

Why It Stands Out

They focus on deeply technical content, not AI-generated fluff, written by people who understand the technology. They offer, as they quote, a 100% happiness guarantee and promise content that's "right the first time" backed by nearly a decade of experience. They're built specifically for enterprise scale and high-volume technical content production.

Best For

Large enterprises requiring high-volume technical content. If you need multiple developer blogs, tutorials, case studies, and customer stories per month for DevOps, fintech, or blockchain audiences, they have the capacity and enterprise experience.

Notable Work

Their client portfolio includes Cisco, Twilio, Circle, and Amazon, with a focus on enterprise-scale content across AI, DevOps, and blockchain topics.

Why Choose Them

You're an enterprise with high-volume content needs and clear specifications. You know what you want and need execution at scale without much strategic consultation.

3. Literally

Literally is a technical content agency that helps early-stage devtool startups with technical content like articles, demo apps, documentation to drive adoption. They work with companies backed by Y Combinator, By Founders, ProFounders, and other major accelerators.

Why It Stands Out

1. The Rubicon Agency

The Rubicon Agency is a specialist technology marketing agency with over 30 years of experience, working exclusively in the information and communications technology sector. They operate across cybersecurity, SaaS, Cloud & AI, engineering & services, infrastructure, and platforms.

Why It Stands Out

They've completed over 4,000 successful technology marketing projects and specialize in surfacing customer context for CISOs, IT leaders, and the C-suite. Their deep expertise in cybersecurity and enterprise IT gives them credibility in technical spaces.

Best For

Cybersecurity companies target CISOs and IT leaders, infrastructure providers, and SaaS companies in technical spaces where credibility with enterprise buyers is crucial. Best when your writers need to credibly discuss threat models, compliance frameworks, zero-trust architectures, or network security.

Notable Work

Their notable clients include Symantec, Red Badger, OpenText, proving years of experience across major technology and cybersecurity brands.

Why Choose Them

You're in cybersecurity or infrastructure and need specialists who thoroughly understand the space. You're targeting enterprise IT buyers and C-suite executives rather than developers.

Final Thoughts

Technical content marketing is a combination of publishing more and being smart.

Developers are skeptical about marketing, so you have to ensure that your content earns trust before it drives conversions. Distribution matters as much as creation.

Select a partner who views content as a strategic growth lever, instead of a checklist item. Someone who bridges technical depth and marketing strategy and understands your audience well enough to speak their language without sounding like a sales pitch.

If you're building for developers or competing where credibility matters more than volume, that strategic fit determines whether your content becomes a competitive advantage or just noise.

Comparing B2B Authentication Providers: A Developer's Perspective

Asjad Ahmed Khan — Wed, 10 Dec 2025 13:12:27 +0000

There have been instances where I have had to juggle authentication while building for teams. The moment your product scales, meaning it moves from individual users to organisations, a lot changes. Suddenly, “Sign-in with Google” doesn’t seem to be doing its trick. You need SSO, SCIM user roles, and various other methods to manage access across workspaces.

Here’s what I learned: most authentication platforms weren't built with B2B architecture in mind. They started as consumer authentication tools, gained popularity, and then retrofitted enterprise features as customers began requesting SSO and SCIM. That restructuring shows up everywhere, from how they handle multi-tenancy to the amount of configuration required to support enterprise customers.

What B2B Authentication Actually Means

Before comparing providers, I need to clarify what B2B authentication requires, because it's fundamentally different from consumer auth at its core.

In consumer apps, you're authenticating individual users. Email/password, social logins, maybe 2FA. Each user is their own entity. Authorization is straightforward; either they're logged in, or they're not.

B2B flips this model completely. Along with authenticating users, you also manage organisations as the primary identity boundary, and users exist within that organisational context. An engineer at Acme Corp needs to log in through Acme's Okta instance. Another customer uses Azure AD. A third uses Google Workspace. They all expect their existing identity provider to work seamlessly with your app.

The Organization-First Model

In B2B systems, the organisation becomes the core unit of identity. Users authenticate individually, but authorisation always flows through their organisation membership. All access control, policies, and resource visibility depend on the organisation context in which they're operating, not just their user identity.

This creates several unique requirements:

1. Multi-tenancy at every layer: A single user may belong to multiple organisations, each with different roles, permissions, and policies. Your authentication system needs to handle organisation switching, where the entire security context changes. Active SSO configuration, role assignments, and access permissions all shift based on which organisation the user is accessing.

2. Email domain routing: Login flows often use email domains to automatically route users to the correct organisation. When someone enters user@goole.com, the system should know this belongs to Google and route them through Google’s IdP. This prevents duplicate tenant creation and auto provisions the login experience.

3. Organisation-level policies: Each organisation enforces its own authentication rules. One might require SSO for all users. Another allows a different passwordless auth but mandates MFA. A third restricts login by IP range or geographic location. Your authentication system needs to consider these organisational policies rather than applying concepts globally.

4. Controlled membership: Unlike consumer apps, where anyone can sign up, B2B systems typically require organisation admins to invite members. You're managing invitation states (pending, accepted, revoked), enforcing domain restrictions, and blocking disposable email addresses.

5. Identity unification: Users might authenticate through SSO one day, use a magic link the next, and or use social login. All these authentication methods need to resolve to a single unified user identity per organisation, not create duplicate user records.

Enterprise Authentication Layer

Enterprise authentication is actually a subset of B2B authentication. It's the specific portion focused on integrating with corporate identity providers and directory services:

1. Organisation-specific SSO: In B2B, each organisation brings its own identity provider. Each org has a unique SSO configuration, SAML metadata, OIDC client IDs, redirect URLs, and IdP identifiers. Your system must determine which organisation's IdP to use based on the email domain or explicit organisation selection during login.

2. Just-in-Time (JIT) provisioning: When an SSO user logs in for the first time, the system automatically creates their user record, assigns organisation membership, maps roles according to IdP attributes, and can bypass email verification for verified enterprise domains. This eliminates manual onboarding friction for large enterprise teams.

3. SCIM directory sync: Enterprise IT departments expect automated user lifecycle management. When someone joins the company, gets promoted, changes departments, or leaves, those changes should sync to your app automatically. SCIM ensures your app mirrors the enterprise directory in near real-time.

4. Self-service admin portal: Enterprises expect a delegated admin flow where their IT team can configure SSO, SCIM, domain verification, and user/role mappings without needing to coordinate with your support team for every change.

The Modern B2B Stack

Beyond enterprise SSO, modern B2B authentication includes:

1. AI and Agent Authentication: With AI agents calling APIs and MCP servers becoming standard, you need OAuth 2.1 flows with PKCE, dynamic client registration, scoped short-lived tokens, and consent management for agent actions.

2. Runtime controls and visibility: Comprehensive logging of authentication events, session management with configurable timeouts, and audit trails that satisfy enterprise compliance requirements.

3. Flexible UI customisation: Branded login pages, admin portals, user profile widgets, organisation switchers, passkey pages, and OAuth consent screens that all feel native to your application.

Most importantly, you need all of this without spending weeks onboarding each enterprise customer or building custom logic for edge cases.

How I Evaluated The Providers

I evaluated five providers for this: ScaleKit, Auth0, WorkOS, Descope, and Stytch. Each takes a different approach to solving B2B authentication, with different trade-offs.

The evaluation focused on what actually matters when shipping B2B features:

1. Setup time: How long from creating an account to having a working SSO flow with a test organisation? Can I complete this in a few hours, or will it take a few days?

2. Developer experience: SDK quality matters because you'll interact with these APIs constantly. Are they intuitive, or do they require constant documentation lookups? Do they follow patterns you're already familiar with?

3. Integration ease: How much refactoring is required? Can it be integrated into an existing app cleanly, or does it require architectural changes?

4. Multi-tenancy handling: Does the platform support an organisation-first architecture, or are you building custom logic to map their user-centric model to your organisation's structure?

5. Customer self-service: Can enterprise customers configure their own SSO and SCIM, or must I act as the middleman, coordinating with IT teams for every configuration change?

6. UI customisation depth: Not just "can I add my logo," but can I customise login pages, admin portals, user profiles, org switchers, and OAuth consent screens to match my product?

7. Pricing model: Some charge per monthly active user (MAU), others per connection, others per organisation (MAO). This has a dramatic impact on economics as you scale. I also looked at whether features are gated behind higher tiers.

8. Documentation and support: Clear, current docs that cover real-world scenarios and edge cases. Responsive support when you hit issues.

What became clear is that there's a fundamental divide in how these tools were built. Some started with consumer authentication and added B2B features later, treating organisations as an afterthought. Others were designed for B2B from the beginning, with multi-tenancy and organisation-first architecture built into the foundation.

Here's how they compare:

Provider	Setup Time	Best For	Pricing Model	Key Strengths
ScaleKit	Under 10 minutes	B2B SaaS & AI apps	First 1M MAUs + 100 MAOs free	Full-stack B2B auth, AI-ready, org-first architecture
Auth0	Days for B2B	Complex requirements across B2C/B2B	First 25K MAU free, for both B2C and B2B use cases	Comprehensive features, battle-tested
WorkOS	Within an hour	Enterprise B2B focus	Per connection for SSO ($125/mo each)	Mature B2B solution, polished APIs
Descope	~30 min (simple flows)	Custom workflows	Varies by usage	Visual workflow builder
Stytch	Few hours for B2B	Passwordless-first	Per MAU	Excellent DX, strong passwordless

ScaleKit

I’m starting with ScaleKit because it’s the only provider in the comparison list that was built from the ground up for B2B authentication.

Setup Time

ScaleKit’s Full Stack Authentication can be up and running in under 10 minutes.

The flow is straightforward. You create an environment, grab your API keys, install the SDK, and you’re authenticating users from their organisation’s SSO. The admin portal, where customers can configure their own SSO, is also included. They provide a fully-hosted admin portal that allows your customers to set up SSO with 20+ IdPs (Custom SAML, Custom OIDC included)

This is the part that surprised me most. With other providers, I was the middleman for every SSO configuration. A customer wants to add Okta? I'm exchanging emails with their IT team, copying metadata XML, and debugging SAML assertions. With ScaleKit, you can implement enterprise-grade SSO with minimal code. They also offer pre-built integrations with major identity providers, including Okta, Microsoft Entra ID, JumpCloud, and OneLogin.

Developer Experience

ScaleKit’s SDK (Node, Python, Go, Java) feels like it was specifically designed for the unique needs of B2B organization and user data models

You can find out more about the SDKs here.

Along with the SDK, what makes ScaleKit easy to integrate is that the entire model is designed around how you actually build B2B apps.

Everything is scoped to organisations. Which includes:

Authentication
Syncing directories

ScaleKit handles edge cases that would otherwise require custom logic, including account deduplication when users sign in through different methods, invitation-based access with state management, pre-signup and pre-session hooks for custom validation logic, domain allowlists and blocklists, conditional authentication based on IP or region, and custom metadata injection during signup and login.

Logging and visibility are comprehensive. Track authentication events, session details, failed login attempts, and agent actions in real-time. Audit logs meet enterprise compliance requirements by providing detailed trails of who accessed what, when, and from where.

Session management includes configurable idle timeouts, maximum session duration, short-lived access tokens with automatic refresh, and automatic logout after inactivity periods.

Integration Flexibility

ScaleKit integrates with existing auth providers if you're already using them. Connect with Auth0, AWS Cognito, Firebase, or Keycloak to validate user identity while using ScaleKit's B2B and AI features on top.

UI Customization

ScaleKit offers extensive UI widget customisation across the entire authentication experience:

1. Hosted login and signup pages: Fully branded and hosted by ScaleKit. Customise colours, logos, fonts, and layout without maintaining frontend code. Launch in days with zero UI work.

2. Admin portal: White-labeled by default with your branding. Customers see your product, not ScaleKit's. Customise themes, colours, and domain (CNAME support).

3. User profile widgets: Drop-in components for users to manage their profile data, view connected accounts, and update security settings. No custom forms or endpoints required.

4. Organisation management: Pre-built widgets for organisation switchers, member management, role assignments, and session policies that admins can access without leaving your application.

5. Passkeys pages: Branded interfaces for users to register and manage passkeys with WebAuthn.

6. OAuth consent screens: Customizable consent flows for agent actions and third-party integrations, showing users exactly what permissions they're granting.

7. Custom emails: Design and deploy authentication emails (magic links, OTPs, account alerts) through your own email provider, fully aligned with your brand identity.

Pricing

The free tier includes 100 monthly active organisations (MAOs), 1 Million Monthly Active Users (MAUs), 1 free SSO/SCIM connection, 10,000 M2M tokens for API authentication, 10,000 M2M tokens for MCP authentication, and passwordless authentication. No feature gating, every feature is unlocked.

Paid tiers are based on MAUs and MAOs, not connections.

Where ScaleKit Fits

ScaleKit is aimed at teams building B2B SaaS or AI applications who want a complete authentication foundation early, with organisation-first multi-tenancy, enterprise SSO and SCIM that customers self-serve, modern passwordless and social auth, AI-ready capabilities for MCP and agent workflows, deep runtime control with comprehensive logs, UI customisation across all surfaces, and pricing that stays predictable as usage grows.

If your roadmap includes modern authentication methods, AI agent integration, and rapid iteration without requiring the purchase of additional products later, ScaleKit is the cleaner long-term bet. It's built for developers who want to ship auth in days, not maintain it for months.

Auth0

Auth0 is what most people think of when it comes to authentication. They’ve been around since 2013 and offer numerous features.

They’re also a perfect example of what happens when a consumer auth platform tries to become an enterprise auth platform. Let’s see this in detail.

The Setup Experience

Getting the basic auth working in Auth0 is fast. Their quickstarts are detailed, the documentation is comprehensive, and you can have an email/password setup running in under an hour.

Adding SSO for a B2B customer? Now, this is an interesting topic of conversation.

You’re connecting to each identity provider. Each connection requires configuration and organisation setup (which incurs an additional cost). You're mapping connections to organisations and configuring login flows with their Universal Login, which means learning their entire customisation system.

Getting a clean SSO using Auth0 can be time-consuming because Auth0 has numerous features and configuration options, making it a project in itself to determine which ones are actually needed.

What Auth0 Does Well

Auth0's SDKs are vast, covering every language and framework. Their features encompass consumer authentication, B2B, B2C, AI agent authentication, and any other authentication method you can think of. The documentation also covers edge cases that most of the providers don’t even mention.

Their Universal Login has improved significantly, and for teams that require fine-grained authorisation with their FGA (Fine-Grained Authorisation) product, Auth0 offers capabilities that surpass what most B2B-focused providers offer.

The Trade-offs

The challenge associated with Auth0 is its complexity. Complexity in the sense that it supports every authentication pattern ever created, which is commendable but overwhelming.

Auth0 uses a per-MAU (Monthly Active User) pricing model.

The free tier includes up to 25,000 MAUs but lacks many features essential for production applications.
Paid plans start at $35/month for B2C Essentials (500 MAUs) and $150/month for B2B Essentials (500 MAUs), with Professional at $240/month for 1,000 MAUs.
For B2B products with thousands of users from single enterprise customers, costs can escalate quickly. The Organisations feature is available on B2B plans but comes with higher base pricing.

When Does Auth0 Make Sense

Auth0 is ideal when you need every authentication method available, have a dedicated team to manage configuration, and budget isn't a primary concern. They're designed for companies where authentication is a crucial part of the product, and precise control over every aspect is required.

For most B2B products, where you just need SSO to work so you can sell to enterprises, Auth0 might be more than necessary.

WorkOS

WorkOS recognised that enterprise authentication was often an afterthought for most providers and developed a solution specifically designed for B2B SaaS.

They’re a good choice at what they do.

Setup and Developer Experience

WorkOS is faster than setting up Auth0 for B2B use cases. Their onboarding focuses on getting SSO working, and the documentation assumes that you’re already building a multi-tenant B2B app. You can have a working SSO flow within hours.

The WorkOS SDKs are cleaned and well-structured. They clearly simplified things compared to Auth0. The API is straightforward: initiate SSO, handle the callback, and get back a user profile. They handle SAML/OIDC complexity under the hood.

Their admin portal is their USP, providing out-of-the-box UI for IT admins to verify domains, configure SSO and Directory Sync connections, and a lot more

What Makes WorkOS Strong

WorkOS was built with B2B in mind from day one. Everything is scoped to organisations. The platform handles SSO, SCIM, and Directory Sync elegantly. Customer reviews consistently praise the quality of their documentation and the responsiveness of their support team.

The free tier is genuinely generous, up to 1 million MAUs for their AuthKit product.

The Pricing Challenge

Per-connection pricing: The challenge with WorkOS is its connection-based pricing model for SSO and Directory Sync. Each SSO connection costs $125/month. While transparent upfront, this becomes expensive as you add more enterprise customers.

If you have 100 enterprise customers, that's $12,500/month just for SSO connections, regardless of how many users actually log in. As one detailed review noted, "the per-connection pricing model creates long-term churn risk due to a pricing model that competitors can easily undercut."

Feature gating: Some features that feel like basic B2B requirements (advanced SCIM capabilities, certain audit log features) are gated behind higher pricing tiers.

When WorkOS Makes Sense

WorkOS is ideal when building B2B solutions with a focused enterprise customer base, where per-connection costs are justified. You want a provider that deeply understands B2B, has a solid track record, and is willing to invest in a premium solution. The main consideration is ensuring your unit economics support the per-connection pricing model at scale.

Descope

Descope takes a visual workflow builder approach. Instead of APIs and SDKs, you drag and drop authentication logic. For simple flows, this is a fast process. The problem comes with customisation. Small changes, such as a single line of code, can transform into finding the right component, configuring its properties, and integrating it into your flow.

What Descope Does Well

The visual approach shines when you need to experiment with different authentication flows quickly and efficiently. You can modify flows without needing to touch code or redeploy them.

Say you want to add step-up authentication for sensitive actions? Drag in the components, and you're done.

Descope's strength is in its flexibility for complex user journeys. Their connector ecosystem integrates with dozens of third-party services for identity verification, fraud prevention, and risk-based authentication. For products that require constant authentication updates, the visual builder streamlines changes.

They also handle both B2C and B2B well, with solid multi-tenancy support and self-service SSO configuration for tenant admins.

The Infrastructure-as-Code Challenge

The problem comes if you're a team that values infrastructure-as-code. Authentication logic lives in visual flows on their platform, not in your codebase. For teams where everything must be versioned in git and reviewable in pull requests, this creates friction.

Descope supports exporting flows as JSON and offers templates for GitHub Actions and Terraform, but you're still managing authentication in a separate system rather than alongside your application code.

When Descope Makes Sense

Descope fits when you prefer visual builders to code, need to iterate on authentication flows quickly without deployments, want both B2C and B2B covered on one platform, your security requirements require adaptive MFA with risk signals, and non-technical team members need to modify authentication flows.

For basic B2B SSO where flows don't change often, and you prefer code-based configuration, it might be more tool than you need.

Stytch

Stytch started in passwordless authentication and expanded into B2B. They excel at what they were designed for.

The Developer Experience

Stytch's documentation and SDKs are clean, and the platform feels comfortable.

Magic link authentication, OTPs, WebAuthn, and biometrics. Stytch handles all modern passwordless methods pretty well. Their embedded authentication approach keeps everything within your application domain, giving you full control over UX.

What Stytch Does Well

Stytch truly shines in passwordless authentication and developer support. Their community Slack, responsive support team, and quality documentation create an exceptional developer experience. Multiple reviews mention switching from Auth0 specifically because of Stytch's superior DX.

Their B2B offering has matured significantly. The embeddable admin portal lets enterprise customers self-serve SSO and SCIM setup. Organisation-first architecture makes multi-tenancy more natural. They support both SAML and OIDC for SSO.

Device fingerprinting, bot detection with 99.99% accuracy, and fraud prevention are built in, which is crucial for B2C applications that deal with account takeover attempts. Intelligent rate limiting and reverse engineering protection add security layers.

Recent additions include M2M (machine-to-machine) authentication for backend services and Connected Apps for cross-application integrations, as well as a shift towards AI workflows.

The Pricing

Stytch uses per-MAU pricing similar to Auth0. For B2B products with many users per organisation, costs can scale quickly. They offer a freemium model, but enterprise features may require higher tiers.

When Stytch Makes Sense

Stytch is ideal for consumer products that require modern passwordless authentication, products that integrate B2B features into existing consumer authentication setups, teams that prioritise superior developer experience and support above all else, applications where reducing signup friction is crucial to conversion, and when passwordless authentication is a core product requirement.

What I Actually Learned

After working with these providers, here's what matters:

1. Auth0 remains the most comprehensive platform. If you need to handle every authentication scenario, B2C, B2B, AI agents, complex authorisation, and have the resources to configure it properly, Auth0 delivers. Their track record and feature depth are unmatched. The trade-offs include complexity, cost at scale (per-MAU pricing), and the learning curve associated with their extensive feature set.

2. WorkOS is the most mature B2B-focused option, excluding full-stack platforms. Their developer experience is excellent, their Admin Portal is genuinely loved by customers, and they thoroughly understand enterprise requirements. The per-connection pricing model ($125/month per enterprise customer) is the main consideration; ensure your unit economics support this at scale.

3. Descope offers something unique with visual workflows. For products where authentication is a living entity that requires constant iteration by non-technical team members, or where complex conditional flows are integral to the UX, Descope's approach makes sense. The drag-and-drop builder trades code control for configuration speed.

4. Stytch offers an excellent developer experience, particularly for passwordless authentication. If you're building a consumer-first experience with some B2B customers, or if reducing friction in signup flows is critical to your conversion metrics, Stytch's approach is compelling. Their recent additions (M2M auth, Connected Apps) show movement toward AI workflows.

5. ScaleKit is purpose-built for modern B2B SaaS and AI applications. It covers the full authentication stack, from basic login to enterprise SSO to AI agent auth, with organisation-first architecture, self-service admin portal, comprehensive UI customisation, AI-ready capabilities (MCP OAuth, token vault for AI apps), and pricing based on users/orgs, not connections.

The Real Decision Criteria

Here's what actually matters when choosing:

1. Architecture fit: Does the provider understand organisation-first multi-tenancy, or are you building custom logic to map their model to yours? B2B products need organisations as the core identity boundary.

2. Time to First SSO: How quickly can you get a customer's SSO up and running? This directly impacts your sales cycle. ScaleKit and WorkOS get you there fastest. Auth0 takes longer due to configuration complexity.

3. Customer self-service: Can customers configure their own SSO and SCIM, or are you the middleman? Being able to send a customer an admin portal link instead of scheduling calls to exchange SAML metadata is transformative. ScaleKit, WorkOS, and Descope all provide this.

4. AI and agent readiness: If your roadmap includes AI features, MCP servers, or agent workflows, does the provider support OAuth 2.1, dynamic client registration, scoped tokens, and consent management? ScaleKit and Auth0 are ahead here.

5. Pricing model and scaling: Understand the unit economics.

Per-MAU (Auth0, Stytch): Costs scale with the total number of users. It can get expensive with large enterprise customers.
Per-connection (WorkOS): $125/month per enterprise customer's SSO. Predictable per customer, but adds up fast.
Per-MAU + per-MAO (ScaleKit): Scales with active users and active organisations. More predictable for B2B.
Custom/usage-based (Descope): Varies based on features and usage patterns.

6. Maintenance burden: Once set up, how often do you touch it? ScaleKit requires minimal maintenance with self-service admin. Auth0 needs regular attention as you add customers and edge cases. Descope requires ongoing flow management in its platform.

7. UI customisation depth: Not just logos, but can you customise login pages, admin portals, user profiles, org switchers, passkeys, OAuth consent, and emails? ScaleKit offers the most comprehensive customisation. Auth0 provides depth, but through their dashboard. Others are more limited.

8. Developer experience: Are the SDKs intuitive, or do they require constant documentation lookups? Stytch and ScaleKit get consistently high marks. WorkOS is clean. Auth0 is powerful but complex.

9. Feature completeness vs. focus: Do you need a platform that does everything (Auth0, Descope), or a focused solution for your specific use case (WorkOS for enterprise B2B, Stytch for passwordless, ScaleKit for either modules or full-stack B2B + AI)?

Choose based on what problem you're actually solving. If you're adding enterprise SSO to close deals and need AI readiness, you want something purpose-built like ScaleKit. If you're building an identity platform with complex requirements across B2C and B2B, Auth0's depth makes sense. If authentication requires constant iteration by non-engineers, Descope's visual approach is effective. If passwordless auth is core to your consumer product strategy, Stytch delivers.

The worst choice is picking a tool optimised for the wrong problem. A B2B product building for enterprises doesn't need to pay for comprehensive consumer features. A consumer app doesn't need per-connection enterprise pricing. An AI application needs OAuth 2.1 and agent workflows, not just traditional SSO.

Match the tool to your actual requirements and roadmap, not to what sounds impressive on paper.

Why Are DevRel Metrics So Siloed?

Mohammed Tahir — Tue, 02 Dec 2025 11:38:35 +0000

A developer stars your repo, asks questions on Discord, reads your documentation, and signs up a week later. For your data workflow, these might be four different people.

Here’s how: GitHub shows the star. Discord logs the username. Your docs platform tracks an anonymous session. The CRM records an email. Nothing connects them. You know conversion happened, but you can't trace it.

When leadership asks, "What's our engagement rate?" or "Which content drives signups?", you're stuck cross-referencing spreadsheets and guessing at matches, ending up with a presentation of cluttered data.

DevRels generate data across many independent platforms, each with different schemas and definitions. GitHub's "active" means something different from your product analytics' "active.

This fragmentation is the result of how the DevRel tools were built.

In this article, we will explore why DevRel metrics often end up siloed, where they originate, how this fragmentation hinders your understanding of the developer journey, and, most importantly, how to address it. We will also show you what a data layer actually is and a tool to practically solve the fragmentation problem, walking you through a real implementation using Google Sheets so you can see exactly how unification works.

Where These Silos Lurk?

Each platform that you use optimises for a single purpose.

GitHub knows usernames and code activity, but doesn't track account IDs or CRM contacts. Discord assigns server-specific user IDs while developers use pseudonyms. Your docs platform tracks anonymous sessions. PostHog uses its own identifier scheme. HubSpot organises around company email addresses. Your backend logs API requests by key. Some data lives in Google Sheets because that's the only export option available.

These tools were never designed to track complete developer journeys. The fragmentation occurs due to issues with the architecture, as each system solves its specific problem beautifully. None were built to see what happens next.

Add schema conflicts on top. GitHub's "created_at" doesn't match your CRM's "signup_date" or your docs analytics' "registration_timestamp." One system defines "active" as logged in this month. Another means made an API call in 30 days. A third counts community messages. When you try to calculate unified metrics, you're comparing incompatible definitions.

This fragmentation creates a downstream problem, affecting your ability to understand what has actually been working and what needs to be changed.

How It Affects the Developer Journey

The moment you can't connect data across sources, your visibility into the developer journey collapses.

A developer discovers you through a conference talk, reads tutorials, stars your repo, asks Discord questions, watches a webinar, and signs up for beta. Which touchpoint mattered? You have no idea because each event lives in a separate system.

Here’s how fragmentation affects your critical workflows:

Attribution becomes guesswork.
Detailed product analysis fails, as “activation” has five different definitions.
Content strategy runs blind when you see what people read, not what they do after reading it.
Community impact remains invisible because it is difficult to connect community members to the downstream outcomes.
Churn signals scatter across systems until it's too late to intervene.

Although the developers are on a continuous journey, your data appears as disconnected events, leading to failed strategies and decision-making that is based on guesses.

This is a problem that requires rethinking your foundation. And a step towards the solution is the data layer.

How Do We Solve This Problem?

A proper solution sits between your fragmented sources and your analysis tools. It must accomplish three things simultaneously:

Unify identity without perfect data

Developers often use different usernames across platforms and frequently remain pseudonymous. A solution needs fuzzy matching that connects "alex_dev" in Discord, "alexcodes" on GitHub, and "alex@company.com" in the CRM. It needs to surface these matches transparently so you can review and override incorrect ones.

Align schemas automatically

Map "signup_date" to "created_at" to "registration_timestamp" into one canonical field. Define what "activation" means across all systems. Maintain lineage so you always know where the numbers originate.

Connect diverse data sources

Pull from code platforms, community tools, docs analytics, product analytics, CRM, backend infrastructure, and spreadsheets. Support APIs and managed ETL for live sync, but also handle exports and manual uploads.

All these requirements are what DevRels actually need to make things more organized for themselves. But is there any medium for us to create the data layers? Yes. One such tool is Astrobee.

In the subsequent sections, we will learn more about it along with practical implementation.

Practical Walkthrough: Unifying DevRel Data with Google Sheets and AstroBee

AstroBee is an AI agent that connects directly to existing data sources and builds a semantic layer capturing business logic as it evolves. Unlike tools that require clean data upfront, AstroBee generates an integrated source of truth from the data you actually have.

There are three connection methods for you to choose from: connect directly to your warehouse so AstroBee analyzes existing datasets without moving or exfiltrating your data (they support any warehouse, including BigQuery, Snowflake, and others, this is typically an enterprise feature since direct integrations require ongoing maintenance), connect source systems like PostHog and HubSpot via Fivetran's managed ETL, or upload CSV files directly.

AstroBee supports Google Sheets, PostHog, HubSpot, Salesforce, Google Analytics, PostgreSQL, and MongoDB. They're always adding new connectors, so feel free to reach out if you need one that isn't currently supported.

The process is simple: Astrobee unifies data and resolves entities, turning multiple definitions of, for example, “user” into a single unified identity. Once unified, you can output via AstroBee's analytics tool or integrate with existing workflows via MCP support; it seamlessly fits alongside your current stack without requiring pipeline refactoring.

To see how this actually works in practice, let's walk through a concrete example.

Creating the Data Layer via Google Sheets
One of the quickest ways to start building a data layer is by using Google Sheets.

For this walkthrough, I created a small dataset within Google Sheets, consisting of three tabs: one for developers, one for events, and one for content assets. Each tab represents a different aspect of the DevRel picture, such as identities, interactions, and the content they have worked on.

You can access the sheet here: https://docs.google.com/spreadsheets/d/1GBbDwscDsZKYwTZ4eAazCFiwKYWljHdfq-FfMt5Kq_0/edit?usp=sharing

The next step would be to utilize Astrobee to create a unified data layer. Here’s how you can do that.

Step 1: Create an account on Astrobee. Navigate here: https://app.astrobee.ai/

Step 2: Once you have created an account, since we’re using Google Sheets, let’s click on Connect Sources.

Step 3: Select Google Sheet as your data source and configure it. As mentioned, AstroBee uses Fivetran to securely connect to Google Sheets. Click “Continue” to proceed.

Step 4: Choose your authentication method and specify which sheet to sync. The setup guide on the right provides detailed instructions from Fivetran. Once you authorise Fivetran, you will be asked to add the sheet link (use the one shared above) and the named range.

After you’ve connected the Google Sheet, you can start creating the data layer to query your data. All you need to do is click “Create Data Layer”, and Astrobee will analyse your spreadsheet structure and generate a business model for natural language queries.

The Result

Here’s a quick demo of the data layer Astrobee generated for us:

Click here to see the video →

Once your data layer is generated, you can explore the tables Astrobee generated by clicking on the Tables tab. Each table represents a key entity from your connected data sources, such as Developer, Content, Event, and other relevant entities, depending on your use case.

Click any table to examine four aspects: Data shows raw data in table format, Description provides generated explanations of what the table represents and how it connects to your business domain, Properties & Relationships reveals all table properties (columns with data types) and relationships to other tables (showing how tables connect via foreign keys), and the SQL tab displays the underlying queries used to generate the table.

Also, notice the Patterns section? Patterns are AstroBee’s way of identifying relationships inside your data, even when the structure isn’t perfect or formally defined.

For the DevRel dataset, one of the first patterns AstroBee detected was a link between the events table and the developers table. Both sheets included a developer_id column, but neither declared a foreign key. AstroBee inferred the relationship by observing the repeated structure across rows and matching values in both tables.

Bringing It All Together

By the time the sheet is connected, identities are resolved, schemas are aligned, and the first set of patterns is validated, DevRels can now gain a clear, connected view of how developers navigate their ecosystem. What started as scattered identifiers across three separate sheets becomes a single narrative that actually reflects how developers discover, evaluate, and adopt your product.

What’s The Benefit for DevRels?

Once DevRels unifies the data, the real value appears in what you can actually do with it.

Complete journey visibility: Trace developers from the first onboarding through every touchpoint. See which content drives progression. Identify where people get stuck.
Real attribution: Stop guessing. Measure which activities are producing outcomes. Connect docs reading to API adoption. Link Discord engagement to retention. Get actual proof.
Churn prediction: API usage drops, GitHub activity goes quiet, and docs consumption stops. Unified, these signals form clear warnings. Intervene before they leave.
Community ROI: Track which developers influenced by advocates are actually converted. Quantify community impact.
Content optimization: Measure what happens after people read your docs. Which tutorials lead to successful implementation? Which guides reduce support burden? And what articles are receiving the most views?

These benefits aren’t theoretical. All of them seem achievable when you have clear and unified data.

Wrapping Up

Most DevRel teams take fragmentation as normal. They accept that proving impact means merely exporting CSV files in reports and assessing outcomes by guesswork.

It doesn’t have to be this way. When data becomes unified, identities are resolved, and schemas align, the work all makes sense, and you can start directing strategies with proper evidence. With this, the decisions land on data that actually connects, and the impact becomes undeniable because it's measurable.

The tools to make this happen are now available. What's left is recognizing that the problem is worth solving and that partial visibility isn't good enough anymore.

To unify the data with Google Sheets and other data sources, check out and get started with Astrobee here: https://www.astrobee.ai/

Hidden Complexities of Scaling GraphQL Federation (And How to Fix Them)

Dalu46 — Wed, 25 Jun 2025 14:00:53 +0000

Federation gives teams the autonomy to move faster, but it also creates a web of hidden dependencies that are easy to overlook, often found in complex distributed systems.

Schema changes can conflict without warning, ownership becomes harder to track, and the federation gateway, responsible for composing and deploying the supergraph, often becomes a single point of friction. Any issue in one subgraph can delay deploys for the entire graph. Platform teams are left responding to problems without the visibility or control to prevent them.

Not every issue causes an outage. Sometimes a deploy gets held back because schema checks fail unexpectedly. At other times, a feature like a product details page returns null because a field was removed from another team’s subgraph.

You may notice that authorization logic behaves differently across multiple services, or stale queries slip past CI because the gateway composition succeeded, but the runtime still fails. Even when teams follow best practices, the graph becomes harder to evolve.

This guide will teach you what starts to strain as GraphQL federation scales. I’ll walk you through the common failure points, the coordination challenges that emerge over time, and how we’ve built Grafbase to help platform teams manage federation without slowing down teams or introducing additional risk.

How cross-team changes create friction in the graph

As the graph grows and more teams contribute, friction becomes harder to contain. These issues stem from the accumulation of edge cases, mismatched assumptions, and operational gaps between teams.

Here’s what that tends to look like in practice:

Schema changes that don’t fail fast. A field gets renamed or restructured in an individual subgraph. Another team’s query still depends on it. The gateway composes cleanly, but the runtime fails. Clients receive nulls, and no one is certain whether the issue originated from the schema, the query, or the deployment process.
Inconsistent conventions across multiple subgraphs. One team returns paginated lists with pageInfo, another returns raw arrays. Errors follow different structures. Without shared review rules or CI checks, the unified API becomes inconsistent for consumers and harder to support.
Deployments are blocked by schema drift. A platform team tries to publish the supergraph, but composition fails due to an uncoordinated change in a subgraph. The deploy is held until that team updates their schema, even if their change had nothing to do with the intended release.
Performance costs from distributed queries. A single client query might pull data from pricing, inventory, and recommendations subgraphs. Each adds a few hundred milliseconds. The end-user sees the total delay, even if each service is fast in isolation.
Drift in authentication, logging, and schema checks. One subgraph uses field-level authentication, while another skips authentication altogether. Some teams log queries; others don’t. Traces are inconsistent, and without shared tooling or policy enforcement, platform teams end up stitching together visibility after things go wrong.

These cases emerge quietly at first, then repeatedly, disrupting your process. They add risk to every deployment and shift platform work toward reactive maintenance instead of scalable support.

What these frictions are costing you

A poorly managed federated graph can increase cognitive load for developers and overwhelm platform teams with issues like schema inconsistencies and network latency. This can lead to application errors, downtime, and even delayed shipping, resulting in lost revenue or deterioration of the organization's reputation.

For instance, one of the common operational pain points in federated architecture is the "all-or-nothing" failure mode, which is frequently debated in community forums, such as this GitHub thread. In such scenarios, when a single subgraph becomes unhealthy or unresponsive, the central GraphQL gateway can fail the entire supergraph, resulting in a system-wide 500 error for clients.

The longer these frictions accumulate, the more you shift your focus from making meaningful improvements to protecting what already exists:

Refactoring shared types becomes too risky: You duplicate fields across subgraphs (with the same purpose, but different names) because it feels safer than coordinating changes across groups.
Ownership becomes unclear: You end up managing schema sequencing, gateway composition, and rollout order, even when you’re not responsible for the underlying services. Time that could be invested in infrastructure or automation is redirected toward conflict resolution.
Schema migrations get delayed: Cleanup tasks remain open for months. Duplicate logic is left in place because you don’t feel confident removing it. You wait until it’s necessary to touch anything shared.
Product decisions are shaped by coordination overhead: You defer exposing new data because integrating it into the unified graph means relying on another team’s schema, and this pressure can sometimes lead to skipping crucial validation steps to avoid a delay in shipping.

By the time you recognize the pattern, it’s already affecting how you plan, test, and deploy your work.

What should scaling GraphQL federation look like?

In a healthy setup, subgraph teams deploy on their own timelines. Schema changes validate cleanly across environments before anything blocks, and ownership is embedded in the schema.

Platform engineers won't spend time chasing rollbacks or patching CI. Instead, they’re working on systems that make the graph easier to evolve.

You should expect:

Schema conflicts are caught early through automated checks across environments. The federated GraphQL schema is designed to be backward compatible.
Auth, logging, and validation are defined within each subgraph but applied consistently across the graph.
Gateway tooling provides clear traces, error context, and actionable insights, enhancing query planning.
There are fewer internal docs and handoffs, so teams can onboard and contribute without friction, leading to a smoother developer experience.
There are coordinated improvements across the platform without disrupting feature development.

That setup is possible, and in the next section, I’ll walk you through how to use Grafbase to achieve this kind of environment, making federation easier to manage as adoption grows without adding overhead.

How to use Grafbase to simplify federation for your enterprise teams

Grafbase is designed to tackle the complexities of a growing federated architecture through its comprehensive approach, focusing on:

Built-in schema validation, observability, and audit-level insight
As mentioned earlier, one of the primary challenges in scaling GraphQL federation is managing schemas across independently evolving subgraphs. For example, imagine managing the schema for a User service and an Orders service as separate entities. If the User service changes a fundamental field, such as id, it could break the Orders service if the Orders service extends the User type based on that id.

Grafbase tackles this through its platform's architecture. By configuring subgraphs via the grafbase.toml, specifying their GraphQL endpoints:

# grafbase.toml

[graphql]
schema = "./schema.graphql"

[subgraphs.accounts]
introspection_url = "http://localhost:4000/graphql"

[subgraphs.orders]
introspection_url = "http://localhost:4001/graphql"

Grafbase automatically introspects these endpoints during local development, pulling the latest schema from each subgraph. This allows teams to iterate on services independently while still catching breaking changes early, before they make it into production.

Grafbase analyzes these schemas and registers them within its schema registry. This registry acts as the source of truth for your GraphQL schemas. During this composition, Grafbase performs automated checks, including build, operation, and lint checks, to identify potential schema inconsistencies before deployment. This validation helps maintain the stability and integrity of the federated API.

The Grafbase Gateway also provides logs, metrics, and traces for monitoring and debugging the federated graph. It even allows viewing schema changes over time via a changelog, and supports custom checks with the grafbase check command to enforce organization-specific rules.

Performance
Built with Rust, Grafbase delivers around 40% faster query speeds and significantly reduced CPU usage. It maintains low latency and consistent performance even during traffic spikes. This ensures fast applications and lower infrastructure costs at any scale.

Security and self-hosting
Grafbase provides security through field-level, WebAssembly (Wasm) based authorization. This allows you to define precisely who is allowed to view specific fields within your GraphQL types. With Wasm, you can attach arbitrary and complex authorizations, granting full access to request and response data and potential Input/Output (I/O) operations. This provides you with the freedom to tailor security policies to your unique data model and business rules, extending beyond simple role-based or type-level authorization.

For companies with specific security and compliance requirements, Grafbase also offers flexibility in deployment options, including crucial self-hosted and air-gapped environments. This simplifies API infrastructure, giving you control over your entire system and data, and ensuring compliance with internal and industry regulations without relying on a fully managed cloud solution.

Customization
Grafbase extensions and hooks are a powerful mechanism for customizing the Grafbase gateway's behavior without the overhead of managing additional infrastructure. This stands in contrast to approaches that utilize external plugins, which must be configured and updated independently. Grafbase extensions make it easier to adopt GraphQL Federation by enabling the declarative integration of services such as authentication, storage, and databases within your schema.

AI-powered API querying
Grafbase features forward-looking capabilities, such as native Model Context Protocol (MCP) support. MCP paves the way for the potential of incorporating AI agents that can query APIs using natural language. From an engineering perspective, this presents new avenues for consumption and interaction with APIs, particularly in high-scale deployments where it can be challenging to familiarize oneself with the entire API surface.

What’s next?

Not every team needs the same federation setup. But the further you scale, the more evident the gap between tools that let you patch things together and platforms built to support distributed teams by default.

Grafbase is designed for that next stage:

Moving from a monolith? Grafbase simplifies the transition by encouraging clear subgraph boundaries and managing the gateway for you.
Managing infra in-house? Use Grafbase declaratively, self-hosted or in the cloud, with native support for CI/CD, caching, and observability.
Migrating off Apollo Gateway? Avoid stitching and manual resolver work. Grafbase automates schema composition without giving up team-level control.
Navigating compliance and access control? Define field-level authentication, RBAC, and isolated preview environments directly within your schema.

If you’re looking for a GraphQL federation setup that prioritizes autonomy and structure, Grafbase might be the shift you’re looking for.

Start with the docs, explore our schema composition guide, or check out the Apollo migration walkthrough to see how Grafbase can help you scale without the friction.

Switching from Hasura to Grafbase: A Step-by-Step Migration Guide

Moronfolu Olufunke — Wed, 25 Jun 2025 10:22:03 +0000

Hasura gained popularity and became widely adopted for its ability to quickly let teams spin up a GraphQL API on top of a relational database, particularly PostgreSQL. That speed makes it a strong early-stage choice. But as systems grow, many teams start running into architectural limits like:

Schema rigidity: Hasura’s API layer is tightly coupled to the database schema, which makes it harder to evolve APIs or decouple logic over time.
Architectural control: Fine-grained control over resolver logic, caching, or gateway behavior is challenging to achieve.
Vendor lock-in: Hasura’s proprietary metadata format introduces vendor lock-in and complicates migration efforts.
Limited extensibility: Adding functionality through actions or remote schemas often requires managing external services, adding friction to development workflows.

If you're starting to hit those limits and exploring alternatives, a more robust solution like Grafbase should be on your radar. Grafbase’s schema-first model supports multiple data sources out of the box, enables declarative federation, and avoids the need to stitch or host separate subgraph services. With the Postgres extension, you can introspect your schema and publish it directly into a federated GraphQL API while controlling how your gateway behaves.

This guide provides practical migration steps to guarantee a smooth migration from Hasura to Grafbase, offers side-by-side comparisons with Hasura, and helps you determine whether Grafbase is the right next step for your team.

Grafbase vs. Hasura: Comparing key concepts

This section compares key features between Hasura and Grabase to help you understand how these core features are translated and handled on each platform.

Feature	Hasura	Grafbase
Schema management	Auto-generated from Postgres	Schema Definition Language (SDL) first, explicit schema definition, declarative GraphQL schema (`schema.graphql`)
Data sources	PostgreSQL (primary), Remote schemas, REST via actions	PostgreSQL, REST, gRPC, Snowflake, Kafka via extensions
API Gateway	Basic built-in API layer; limited control over gateway behavior	GraphQL Gateway with custom resolvers, and federated subgraphs
CLI	`hasura-cli` for migrations, metadata, and project management	`grabase` CLI for local dev, schema introspection, publishing, and gateway setup
Schema registry	No native schema registry or versioning; schema can be exported via introspection or the console	Built-in schema registry, versioning, schema validation with Grafbase check

To dig deeper into how the two tools compare, this Hasura alternative guide covers more architectural and workflow-level differences. You’ll also find platform-specific details in the Grafbase docs if you're exploring a larger rollout across teams or environments.

Once you are familiar with what Grafbase offers, the next step is learning how to implement it. The following sections guide you through each stage of the process, including exporting Hasura metadata, generating your Grafbase schema, configuring subgraphs, and deploying via the Grafbase Gateway.

Preparing for migration

Before starting your migration, audit your current setup and align your team on what a successful switch looks like. Use this checklist to make sure your team is ready for migration:

Audit Hasura setup: List all tables, relationships, permissions, actions, event triggers, and remote schemas in use.
Identify business logic: Document any implemented custom logic.
Map auth flows: Understand your current authentication and authorization setup.
List integrations: Note any webhooks, REST endpoints, or third-party integrations.
Set clear migration goals: Get your team on board, make sure everyone agrees on the plan, and define the migration objectives.

Migration tools

You’ll need to have these tools installed:

Step-by-step migration process

We’ll build a small demo project with features like custom actions and remote schema (REST API) to demonstrate how to safely migrate a real Hasura setup to Grafbase.

1. Export Hasura metadata

As mentioned earlier, you need to audit your Hasura setup before the migration process. Start by exporting your Hasura metadata via the CLI by running:

hasura metadata export

Alternatively, you can also use the Hasura console or API which is part of the Hasura open source framework.

This will instantly generate a metadata containing configuration data about your Hasura actions, remote schemas, custom types, and more. Study them carefully, as these will help you shape your Grafbase schema.

2. Generate a federated GraphQL schema

The next step is to generate GraphQL schema. Even if your database is complex, the Grafbase PostgreSQL extension makes it easier to convert and translate the exported Hasura metadata for use in Grafbase. This extension also helps teams generate a GraphQL schema from an existing PostgreSQL database.

To generate the GraphQL schema, follow these steps:
a. Make sure you have installed the Grabase CLI and the Grafbase Postgres extension.
b. Next, create a grafbase-postgres.toml configuration file in your project and add this:

# Change this to reflect the version of the extension you want to use.
extension_url = "https://grafbase.com/extensions/postgres/0.4.7"

# The generated SDL needs to know in which schema the type comes from.
# If the schema name is not written in the schema, Grafbase will use this value.
default_schema = "public"

# The name of the database in the Grafbase configuration.
database_name = "default"

c. Next, introspect your database and generate a GraphQL schema by running:

grafbase postgres \
  --database-url "postgres://postgres:user@password:5432/your_db_name" \
  introspect > schema.graphql

This will generate a schema.graphql file that represents your database schema.

3. Configure the project

Next, within your project, create a grafbase.toml file to configure the Postgres extension and point to the generated schema:

[extensions.postgres]
# Change to the latest version.
version = "0.4.7"

[[extensions.postgres.config.databases]]
name = "default" # This must match the name in the grafbase-postgres.toml
url = "postgres://postgres:user@password:5432/your_db_name"

[subgraphs.postgres]
schema_path = "./schema.graphql"

Test the success of the SDL generation and launch the development server by running:

grafbase dev

Navigate to http://127.0.0.1:5000 in your browser to explore the generated schema.

With the Postgres subgraph deployed, let’s now federate an external REST API into the graph.

4. Publish the Postgres subgraph

Once you're ready, first create a new graph in the Grafbase Dashboard. Next, publish the Postgres schema to the Grafbase platform as a virtual subgraph using this command:

grafbase publish \
--name postgres \
<name-of-org>/<name-of-graph>@<branch> \
--schema schema.graphql \
--virtual

This lets you map your database into a federated graph with no intermediate API layer, no stitching, and no subgraph service to maintain.

You can do this for as many schemas as you have. But what happens if you have REST APIs to federate?

5. Migrate remote schemas

Grafbase provides different extensions to extend federated graphs. One such extension is the REST extension, which, when integrated, enables you to define REST endpoints and map them to GraphQL fields using two directives: @restEndpoint and @rest .

To use this REST extension, you must create a new schema file separate from your Postgres schema, as Grafbase requires that Postgres and REST extensions reside in different subgraphs.

This example uses the publicly available fake store REST API. Follow these steps to see how you will use it in Grafbase:

a. Add the REST extension: In the grafbase.toml file, add the code below to install the REST extension, then add the link to the new REST schema you created. Like so:

[extensions.rest]
version = "0.4.1"

[subgraphs.rest]
schema_path = "./rest-schema.graphql"

Run grafbase extension install to install the newly added REST extension into the grafbase_extensions directory. This command installs any extensions declared in the grafbase.toml that are not yet installed.

b. Define the REST schema: In the newly created REST schema file, add this code:

extend schema
  @link(
    url: "https://grafbase.com/extensions/rest/0.4.1"
    import: ["@restEndpoint", "@rest"]
  )
  @restEndpoint(name: "restProducts", baseURL: "https://fakestoreapi.com")
type RestProducts {
  title: String!
  price: Float!
  description: String!
  category: String!
  image: String!
}
type Query {
  getAllRestProducts: [RestProducts!]!
    @rest(
      method: GET
      endpoint: "restProducts"
      path: "/products"
      selection: """
      [.[] | {
        title: .title,
        price: .price,
        description: .description,
        category: .category,
        image: .image
      }]
      """
    )
}

This code fetches product data from a public REST API (fakestoreapi.com) and exposes it as a GraphQL query (getAllRestProducts) using Grafbase’s REST extension.

Test locally by saving, stopping your local development environment, and then running grafbase dev again. It’s as simple as that!

c. Publish the REST subgraph: Now, you can publish this new subgraph to the Grafbase platform by running the deploy command you used previously, but with a change to reflect the name of the subgraph you want to publish and the path to the current local schema:

grafbase publish \
--name rest \
<name-of-org>/<name-of-graph>@<branch> \
--schema rest-schema.graphql \
--virtual

Integrating REST APIs typically requires setting up Actions in Hasura, which can involve complex configuration. By contrast, as demonstrated above, this was accomplished in just three straightforward steps on Grafbase.

6. Combine and deploy subgraphs with the Grafbase Gateway

After publishing the new subgraph, you can deploy the federated graph using the Grafbase Gateway. The gateway automatically keeps up with subgraph updates and unifies different subgraphs into a single federated graph for querying. In this case, it will federate the Postgres and REST subgraphs.

Follow these steps to deploy:
a. Create an access token in the Grafbase organization settings.

b. Export the access token and start the gateway using this command:

export GRAFBASE_ACCESS_TOKEN="ey..." //exported token

c. Start the gateway by running:

grafbase-gateway --graph-ref name-of-graph --config grafbase.toml

The --config argument is optional, but to start the gateway with a graph ref, the access token is mandatory.

You now have the schema registry populated, the gateway set up, and the federated graph on Grafbase up and running. You can send queries to the Grafbase Gateway and observe it in action with your Federated Graph.

Refer to the Grafbase Postgres extension guide for more information on features, configuration options, and running the gateway.

Post-migration tips

On successful migration from Hasura to Grafbase, it's also essential to validate and optimize your new setup. Here’s a checklist of what to test and monitor post-migration:

Query parity between systems

Confirm that all critical and/or complex queries and mutations behave as expected and return the same data structures and values as they did in Hasura.

Additionally, to verify schema consistency between the exported Hasura metadata and the generated schema on Grafbase, run:

diff name_ofhasura_metadata.graphql name_of_grafbase_schema.graphql

This will show you line-by-line differences between your Hasura-generated schema and your Grafbase schema, helping you identify mismatches or missing types and fields.

Set up schema checks

Using the grafbase check command, you can check your schema against the Grafbase Platform. This will help you safeguard against introducing breaking changes or errors into your GraphQL API, especially when working in multiple teams. Read more on the dedicated docs page.

Deployment configuration (cloud services or self-hosted)

Validate that tokens, secrets, and environment variables are securely stored and accessible in your cloud or container platform.

Subgraphs management

Organize schemas and group related functionality into logical subgraphs for modularity and clarity.

Observe latency and performance changes

Without relying on external tools like Grafana or Datadog, Grafbase provides built-in solutions for telemetry and observability features. You can benchmark workload and key metrics after migration, and use the Grafbase dashboard to view insights and analytics on error rates and slow responses, helping you to detect regressions proactively.

Horizontal scaling

Monitor how your federated graph performs as you add more subgraphs or services. Grafbase’s gateway is designed to scale, but you’ll still want observability in place.

There are additional steps to verify success after migration, but taking the above as a starting point is a great approach.

Troubleshooting mixing resolver extensions in the same subgraph

You might encounter the following error when starting the federated gateway:

Error: could not start the federated gateway
Caused by: Error validating federated SDL: Selection Set Resolver extension postgres-0.4.1 cannot be mixed with other resolvers in subgraph 'postgres', found rest-0.4.1

Cause: This error occurs when you try to use both the Postgres and REST resolver extensions in a single subgraph (in this case, using REST extension in the Postgres subgraph). Grafbase doesn't support combining multiple selection set resolver extensions (such as @postgres and @rest) within the same subgraph.

Solution: Separate the conflicting extensions into distinct subgraphs. For example, if your Postgres subgraph already uses the @postgres extension, create a new subgraph (e.g., rest) for REST-based resolvers and configure it independently in your grafbase.toml.

These benefits are available to you after migration

Now that you have seen how to easily migrate from Hasura to Grafbase, here’s a summary of some advantages that the highlighted Grafbase features provide for your team and how they help you scale beyond Hasura’s limitations.

Hasura limitations	Grafbase solution
Schema rigidity	Grafbase uses a schema-first approach. As such, it lets you compose your GraphQL schema from multiple sources (databases, APIs) rather than binding it directly to a single database schema.
Architectural control	Grafbase provides more granular control over caching strategies and gateway behavior. Its Edge Gateway allows you to orchestrate all your data fetching and optimize performance at the gateway layer, rather than being restricted to database-driven resolvers.
Vendor lock-in	Grafbase avoids proprietary metadata formats tightly coupled to its runtime. Its approach is to use standard GraphQL schemas and open configuration, making migration and integration with other tools less risky and complex.
Limited extensibility	Grafbase is designed for extensibility, allowing you to connect multiple APIs and services and implement domain-specific logic directly within your schema.

Wrapping up

For teams running into Hasura’s limitations, exploring alternatives like Grafbase provides benefits that make it a worthwhile move.. The benefits include long-term flexibility and maintainability, improved API architecture, enhanced developer productivity, and experience. Grafbase also provides more control over your GraphQL gateway and production-grade federation support.

Ready to try it out? Get started with Grafbase and migrate your federated graph to Grafbase in minutes.

Get Started with Serverless Architectures: Top Tools You Need to Know

Dalu46 — Tue, 01 Apr 2025 23:47:36 +0000

Managing the infrastructure to host and execute backend code requires you to size, provision, and scale several servers, apply security patches, and then manage operating system updates and infrastructure for performance and availability.

Wouldn't it be great if you could build out your application without spending time managing servers? That's the whole idea behind serverless architecture.

This article will guide you through the essential tools for adopting serverless architecture, offering a practical roadmap to get started. It aims to demystify the serverless ecosystem and highlight key technologies.

What Does Serverless Really Mean?

One of the most common misconceptions in the industry is that going serverless means eliminating servers entirely. In contrast, it just means removing them from the developer’s perspective. At the end, there is a server running your application code. Serverless just means that you don’t operate them. The cloud providers (e.g., AWS Lambda and Azure Functions) handle the infrastructure, allowing you to focus on your code.

Think of ordering food from your favorite restaurants. You have great food without needing to shop, cook, or clean. Serverless computing is pretty much the same: you run your code without managing the servers.

As your application grows and gains many users worldwide, processing data becomes complex and demands scaling. This will require handling downtime, reducing latency, and managing servers, which results in additional costs and resources. By adopting serverless architecture, larger applications can run faster with lower costs and resources.

Serverless architecture is well-suited for web and mobile applications with different workloads. Examples are real-time data processing apps like chat apps, backend for frontend services (BFF) apps like e-commerce apps, automation and scheduled tasks apps like task manager apps, and more.

Key Benefits of Serverless Architecture

There are many other reasons why going serverless is a good design choice over managing your servers yourself. Here are the most essential ones:

Cost-Effectiveness: Serverless architecture uses a pay-as-you-go model; you pay only for what you use. This method can significantly reduce operational expenses, which is great for developers with strict budgets.
Lower DevOps Requirements: Developers or businesses using serverless platforms do not need to spend on hiring and training DevOps resources, as server operations are managed for them. Instead, it allows the engineering team to focus on application development.
High Availability: Serverless platforms generally offer high availability by distributing functions across multiple data centers or regions. This built-in redundancy enhances application reliability and reduces the risk of downtime.
Scalability: Serverless solutions scale up and down automatically, responding to changing workloads without manual provisioning. This allows you to quickly increase your resources anytime without being concerned about the server's capacity as it scales.

Top Serverless Tools for Compute, Storage, and Databases

This section will discuss the top serverless tools that will give you an edge while getting started with serverless architecture. It will be divided into serverless compute tools and serverless databases.

Serverless compute tools

Here are the top serverless cloud providers. While each platform has distinct features and advantages, they allow developers to focus on writing code rather than managing servers.

AWS Lambda
AWS Lambda is a compute service that runs your backend code in response to events such as object uploads and HTTP requests.
It automatically handles all the capacity, patching, scaling, and administration of the infrastructure to run your AWS Lambda functions.
Lambda also provides visibility and performance and automatically manages the computing resources, making it easy to build applications that respond quickly to new information.
Like other serverless providers, Lambda as a service doesn't come with built-in storage.
Lambda functions are stateless; each invocation is considered a clean slate.
Nevertheless, Lambda functions can work with additional services that provide storage.
Common examples include S3 (Simple Storage Service), EFS (Elastic File System), and databases like RDS, Neon, and DynamoDB.

Use Case

AWS Lambda is perfect for applications that process images due to its integration with AWS S3, an object storage service. A good example is an e-commerce application that renders images in different sizes.
Here are the top features:
- Monitoring and Logging: Lambda integrates with Amazon CloudWatch for monitoring and logging, providing insights into function performance and errors.
- Multi-language Support: AWS Lambda supports multiple programming languages.
Azure Functions
Azure Functions is a function-as-a-service in Microsoft Azure that runs small pieces of code or "functions" in the cloud.
Functions are executed by a trigger (an action that invokes the code).
Azure Functions is an extension of the Azure App Service.
Azure Functions focus on event-driven scenarios and provide on-demand compute resources required for your applications.
You can use Azure Functions to build web APIs, respond to database changes, process IoT streams, manage messaging queues, and more.

Use Case

Azure Functions integrates with most tools in the Microsoft ecosystem, including Azure Queue (adding messages to a queue) and SignalR (sending real-time updates). This makes Azure Functions the perfect choice for real-time applications like chat apps.
Here are the top features:
- It supports multiple languages, including C#, Java, Python, PowerShell, and TypeScript, and it can extend its language support to languages such as Go.
- Microsoft Azure offers single-pane operations, a powerful feature that provides a unified view of hybrid environments via the Operation Management Suite (OMS), a Management-as-a-Service (MaaS).
- It allows monitoring and management of various data sources, including storage, virtual network services, machines, logs, and insights.
- Flexible development with integrations with GitHub and Azure DevOps.
- The entire SDK for functions is open-source.
Google Cloud Functions
Google Cloud Functions is a scalable serverless execution environment for building and connecting cloud services. It provides triggers automatically, with out-of-the-box support for HTTP and event-driven triggers from GCP services.
There are two types of Google Cloud Functions: API cloud functions and event-driven cloud functions.
The API cloud functions are invoked from standard HTTP requests, while the events-driven cloud functions handle events from the cloud infrastructure.
The event driver provides you with a trigger, which is stored in the data, and then sends you a response according to your function.

Use Case

Out of all the tools in this list, Google Cloud Functions is the best for image analysis.
While AWS Lambda is good for processing images, Google Cloud Functions is the perfect choice for applications that require image analysis because of its integration with Google Cloud Vision API. It is excellent for building social media applications and applications with face recognition.
Here are its key features:
- Allows configuration of functions based on the application's need, enabling trigger-based execution, memory and CPU allocation, and scaling controls.
- Allows configuring an instance to complete multiple concurrent requests.
- Automatic provisioning of resources.
- Simplified and intuitive developer experience.
Cloudflare Workers
Cloudflare Workers is a serverless computing platform that allows users to create or augment existing serverless applications. Unlike most serverless platforms, it requires little configuration and no region selection, enabling users to deploy applications anywhere on Earth.

Use Case

It’s best for geo-location content delivery applications because of its low latency and edge network spread around the globe. Examples are live streaming apps, online games, product apps that show products and currency based on the users' location, and so on.
Here are the key features:
- It is fast and runs on lightweight V8 isolates.
- Easy deployments with just a little configuration.
- High-performance global network.
- Cloudflare Workers use the same network that runs Cloudflare content delivery network, load balancing, web application firewall, and more, leading to faster performance.

Serverless databases

Here are the top serverless databases with their key features and use cases:

Neon
Neon is a serverless Postgres database that scales up and down based on your application workload by separating storage and computing. When you develop your app, you don’t need to worry about the cost of using it. Neon scales to zero when the database is not in use. When you deploy your app to production, you don’t need to worry about the capacity of your database; Neon automatically scales to the demands of your workload. It’s the perfect database for working with serverless architecture.
Neon applications can be deployed traditionally and connected over TCP using any Postgres driver. However, more teams are leveraging edge deployment in environments where they can’t establish a direct TCP connection, such as Cloudflare workers, AWS Lambda, and Vercel Edge functions. Neon provides a low-latency serverless driver for such deployments, working over both WebSockets and HTTP for efficient real-time and request-based interactions.

Use Cases

Neon is best for building modern, data-driven, and SaaS applications. An example is a subscription-based analytics app with real-time customer insights for different businesses.
Here are the key features:
- Provides database read replica, a feature that allows replicating databases, enabling you to provide read-only access without duplicating data.
- Provides API and CLI tools for database management.
- It’s cost-efficient, as your costs are directly tied to the resources your workload consumes—you don't pay for idle capacity.
- Integrates with any language or framework and supports over 70 Postgres extensions.
- Neon uses PgBouncer for connection pooling.
Firebase
Firebase is a serverless app development platform based on Google Cloud. It integrates with several other Google products, such as analytics, and provides client-side SDKs for building iOS, Android, and web applications.
Firebase offers Cloud Functions edge deployments, enabling the serverless execution of backend code in response to events triggered by HTTPS requests. This allows you to build responsive and scalable applications without managing servers.

Use Cases

Firebase is great for building real-time applications that work with media content like images, videos, and audio. Examples are social media applications and e-commerce apps that have real-time customer support.
Here are its key features:
- Offers fast and secure static web hosting with global CDN delivery.
- Provides out-of-the-box authentication with support for multiple providers like Google, Facebook, and email with password.
- It comes with Firestore and Realtime Database. These are scalable NoSQL databases for storing data and building interactive applications.

Building A Simple Serverless API

To fully understand serverless architecture, let’s build a simple application to see how it works. This section will walk you through a step-by-step guide to building a simple serverless API using Cloudflare Workers and Neon, a serverless Postgres database.

Getting Started

First, create an account at neon.tech. Once you have an account, click Create a new project and name it serverless_api.

Next, click on Dashboard → Connect, then copy the connection string. Keep it safe because you will need it to connect with Cloudflare Workers.

Create a Cloudflare Worker

Name your Worker, serverless-api, and click Deploy.

Once the Worker is deployed, you will be directed to the Worker editor page, where you can write your Worker code directly in the browser. In a real application, you would write the logic to query your Neon database. However, the API will return a simple “Hello Serverless World” text for this application.

Connect Cloudflare Worker with Neon

On the sidebar, click Compute (Workers) → Workers & Pages → Integrations, then select Neon and click Add Integration.

Follow the prompt. You will be asked to authorize Neon and select the project, branch, and database. Cloudflare will automatically show your Neon connection string. Compare it with the one you have retrieved from Neon to confirm.

These Secrets will be added to the existing Environment Variables of this Worker.

Once that is done, Cloudflare will provide an endpoint that you can fetch in frontend code, similar to this:

https://serverless-api.<your email>.workers.dev/

You can also test the serverless function in the preview browser on the Cloudflare console.

In the Worker.js file, paste the following code:

    export default {
      async fetch(request, env, ctx) {
        console.log(env)
        return new Response('Hello Severless World!');
      },
    };

This will return a simple Hello World and log the Neon connection string in the console to show that the database was successfully connected.

You may ask why a serverless API is needed when you could query the database directly. Well, the answer is simple: as soon as the application begins to grow, there will be lots of users calling that API (function). However, since the serverless provider automatically handles scalability, your server will be able to handle the change in workload without crashing. If you want a more extensive tutorial on building a serverless application with Cloudflare Workers and Neon, check this tutorial.

Wrapping Up

Serverless computing offers a powerful approach to building modern applications, enabling automatic scaling, low cost, and faster response time. By using the right tools, such as AWS Lambda, Google Cloud Functions, Cloudflare Workers, and Neon for databases, you can simplify development while reducing infrastructure complexity.

Curious about Neon’s capabilities? Sign up today and experience hassle-free, serverless PostgreSQL!

Run Postgres For Free: Top 3 Options

Femi-ige Muyiwa — Thu, 27 Mar 2025 12:29:29 +0000

“When life gives you lemons, TAKE THEM; free stuff is cool.” ~ Teo Deleanu.

And when life gives you PostgreSQL for free, you take that too. Why? Because taking free stuff isn’t just cool; it’s the smartest thing to do. Whether you’re a developer building a side project or a startup testing the waters, running PostgreSQL without breaking the bank is a win-win.

This article will show you the three top options for running PostgreSQL databases for free, from exploring some modern cloud hosting options to setting them up for development.

By the end of this article, you’ll know:

How do these platforms compare?
Which free-tier hosting platforms are the best (and what are their limitations)?

Why PostgreSQL?

PostgreSQL is a powerful open-source database that is constantly improved by a large community of developers. It supports familiar SQL queries, making it easy to use while offering the flexibility and reliability needed for modern full-stack apps. With over 35 years of open-source excellence, it is one of the greatest relational databases of all time, trusted by developers worldwide. It is a truly open-source project with no hidden licensing fees, making it a cost-effective choice for any project.

Also, PostgreSQL is known for its rock-solid data integrity as it follows the Atomicity, Consistency, Isolation, and Durability principles (ACID). In doing so, PostgreSQL never loses, corrupts, or allows inconsistent data, which is critical for applications like banking and healthcare.

One of PostgreSQL’s standout features is its concurrency handling through its Multi-Version Concurrency Control (MVCC). This feature allows multiple transactions to read the same data without blocking writes. Here is an SQL query that represents two database transactions running in separate sessions:

-- Transaction 1 (Session A)
BEGIN;
SELECT * FROM orders WHERE id = 1; -- Reads the current state
UPDATE orders SET status = 'shipped' WHERE id = 1;
COMMIT;

-- Transaction 2 (Session B)
BEGIN;
SELECT * FROM orders WHERE id = 1; -- Reads the old state before the update in Session A is committed
COMMIT;

With this technique, Session B sees a consistent snapshot of the data without being blocked by Session A’s update, making PostgreSQL a reliable choice for highly concurrent apps such as e-commerce, finance, and collaborative platforms.

Now, the moment you’ve been waiting for: here are the top three free-tier hosting solutions for the Postgres database. You’ll get to see why developers love them, as well as a quick start guide and some of their limitations.

Managed Postgres Comparison Table

Here is a like-for-like comparison table summarizing the features of some of the best free-tier Postgres hosting platforms.

Feature	Neon	Aiven	Render
Ease of Use	Easiest for beginners – Instant provisioning, database branching, and serverless architecture.	Moderate – Supports multiple open-source technologies but limited to one service on the free plan.	Moderate – Unified platform but limited to one free database instance.
Free Tier Storage Disk Space	0.5 GB	5 GB	1 GB
Compute Hours	191.9h/month	Not specified	Not specified
Postgres Versions	17, 16, 15, 14	17, 16, 15, 14, 13	16, 15, 14, 13
Database Branching	Yes (Full data branching and Schema-only branching BETA)	No	No
Cloud Providers	Multiple (AWS and Azure)	Single (DigitalOcean)	Single (AWS)
Limitations	Autoscaling can burn through compute hours.	Max 20 connections, no connection pooling.	30-day limit, no backups, single instance only.
Best For	large enterprise workloads as well as small projects, MVPs, and scalable applications.	Testing and small projects.	Small development and testing.

Neon

Neon provides a cloud-based, scalable implementation of PostgreSQL that can run on your physical hardware or through their managed services. Its architecture is separated into “compute” (for Postgres) and “storage” (a multi-tenant key-value store for Postgres pages), allowing Neon to gain true serverless capabilities.

Separating these architectures allows Neon to autoscale its compute resources depending on the activity period while maintaining data separately in a multi-tenant storage system. This architecture allows users to set up resources as soon as requested (instant provisioning), making it effective for managing costs since you only pay for the compute resources you use. This approach makes Neon reliable and cost-efficient compared to traditional database architectures, where storage and computing are tightly coupled.

Why Developers Love Neon
Neon offers a generous free tier option, enabling developers to build small projects and MVPs for a good period of time. Here are some of the benefits of the Neon PostgreSQL free tier:

You can have up to 10 projects, with each project able to own 10 branches.
Supports connection pooling through PgBouncer, enabling up to 10,000 concurrent connections.
Provides automatic backups through its "Point-in-Time Restore" (PITR) feature.
Database branching: This option allows you to create different environments (Dev, Staging, and Production) for your Postgres. You can also create some backup, as a new branch always contains data from the main branch.
The free tier offers a 0.5 GB storage limit, 191.9 compute hours/month, and 5GB of data transfer.
It supports Postgres versions 17, 16, 15, and 14.
Supports multiple cloud service providers and has access to all regions available to these providers.

Quick Start Guide
You can sign up to Neon using an email and password or with other third-party providers like Google, GitHub, or Microsoft. Then, create a new project using any configuration you prefer.

Limitation
Though autoscaling can improve performance during high-activity periods, it can easily burn through the compute hours during the free trial.

Aiven

Unlike Neon, Aiven provides many open-source managed data infrastructures, such as PostgreSQL Apache Cassandra, Apache Kafka, Apache Kafka Connect, Apache Kafka MirrorMaker 2, Elasticsearch, Grafana, InfluxDB, M3, M3 Aggregator, MySQL, and Redis. It’s a jack of all trades regarding its support for open-source technology.

Why Developers Love Aiven
Aiven supports deployment across various cloud providers, allowing users to choose the best infrastructure for their needs. Aiven offers access to its service using the free plan (PostgreSQL, MySQL, ValKey) or a 30-day free trial. When using the free plan, you can only access one service, but Aiven offers a 30-day free trial that can allow you to access all the services.

Aiven for PostgreSQL is a fully managed and hosted relational database service, and it offers features that developers can use indefinitely, such as:

It supports Postgres versions 17, 16, 15, 14, and 13.
The free tier consists of a single node, 1 CPU per virtual machine, 1 GB of RAM, and 5 GB of disk storage.
Management through the Aiven Console, CLI, API, Terraform Provider, or Kubernetes Operator.
Monitoring for metrics and logs.
Supports backups for disaster recovery.

Quick Start Guide
You can sign up to Aiven using an email or with any of its third-party authentication provider options. Afterward, you must log in to the console and follow the onboarding process to complete your registration.

Once you finish that, you are greeted with a page listing services you can create. Select the PostgreSQL service and set up your service using your desired configuration, then click ‘Create free service’ to deploy.

Limitations
Here are some of the limits to consider when using Aiven Postgres free tier:

It only supports a maximum of 20 connections, and connection pooling is not available to help manage multiple client connections.
Limited support: Aiven doesn’t provide access to dedicated support teams and, instead, relies solely on the Aiven Community Forum for user assistance.
The free plan is not covered by the Aiven Service Level Agreement.
A single cloud provider (DigitalOcean), limited service region, and service plan for the free plan.

Render

Render is a more traditional hosting platform that can build and deploy your applications, websites, and databases. As a unified platform, Render is an awesome choice for both seasoned developers and beginners, as you do not have to worry about using multiple platforms to host your application and your database(s). It can run various projects, from static sites and web applications to background workers, APIs, cron jobs, and managed databases.

Why Developers Love Render
Apart from Render’s user-friendly interface, it offers a free PostgreSQL hosting plan for development and testing, hobby projects, and MVPs. Here is an overview of some of its features and benefits:

Fixed Resource Allocation: The free PostgreSQL plan provides 256 MB RAM, 1 GB storage capacity, and 0.1 CPU, which can be enough for small-scale development.
It supports Postgres versions 16, 15, 14, and 13.
The free PostgreSQL plan has all regions available to other paid plans.
It allows you to integrate your PostgreSQL database with the other services available to Render. So, if you have an existing project hosted on Render and want to host a database for that project, Render gives you the option to do that during the database setup.

Quick Start Guide
Sign up to Render using an email or any third-party authentication provider option. Afterward, you will be greeted with various service types that Render offers. Select New PostgreSQL and set up the service with your desired configurations.

Limitations
Here are some of the limitations to consider when choosing the free tier option for Render:

The Free PostgreSQL database has a 30-day limit and will expire after that deadline. It has a 14-day grace period after the deadline, which will cause Render to delete the database if you do not update the plan.
It has a single instance limit for the PostgreSQL database. You can have only one active Free PostgreSQL database for any given workspace.
It doesn't support database backups.
Downtime or maintenance would cause the database to be temporarily unavailable.

Final Thoughts

Neon, Aiven, and Render are outstanding, cost-effective database options with great value. Each has standout features that, depending on your needs, can give you a great developer experience:

Neon stands out with its serverless architecture and developer-friendly features, such as database branching and generous compute hours. Its instant provisioning and transparent resource allocation make it perfect for large enterprises, rapid prototyping, and early-stage startups.
Aiven delivers reliability with its fixed 5GB storage and support for multiple Postgres versions. While the free tier is limited to one service, its monitoring tools and backup support make it ideal for learning and small production workloads.
Render shines with its unified platform approach, letting you host your applications and databases in one place. Though time-limited, its straightforward setup and integration capabilities make it an excellent choice for full-stack applications.

So, what are you waiting for? Pick the best platform for your project and start building today without spending a dime!

Resources

If you're considering using PostgreSQL the traditional way, here are guides to install it on macOS, Linux, or Windows:

This Is Why You Should Use Cloudflare Workers

Dalu46 — Sat, 15 Mar 2025 15:12:43 +0000

Cloudflare Workers are serverless edge-computing providers that allow users to create or augment existing serverless applications. It uses the V8 engine under the hood, the same engine used by Node.js and Chromium. These Workers are deployed all around the globe to process data closer to your users, yielding faster responses and improving processing speed.

Building large-scale applications requires rigorous infrastructure and server management. Cloudflare Workers eliminate this burden by deploying and managing your code. They handle issues related to downtimes due to heavy traffic and have low latency, which improves your application's performance.

By the end of this article, you will understand the benefits of Cloudflare Workers and how they differ from other serverless platforms like AWS Lambda. You will also learn about Neon's serverless capabilities, the benefits of using Neon database, and how you can use Neon with Cloudflare Workers to build your application.

Why use Cloudflare Workers

Large applications with millions of users worldwide require complex data processing. Usually, the necessary servers for storing and processing data are in more than one physical location worldwide. To ensure the application runs smoothly, large applications require complex procedures such as configurations, database maintenance, and automation, which lead to additional costs and resources.

If you are looking to build scalable applications, some of the benefits of using Cloudflare Workers over other serverless providers are:

Minimal Latency: Because Cloudflare Workers deploy your code across its global network, there is less distance between your data and your users’ devices. As a result, your application loads and processes faster.
Scalability: As your application scales, handling client requests and managing your servers becomes tedious. Cloudflare Workers solve this issue by storing and processing your code, minimizing downtime, and ensuring your application remains accessible.
Cost: Cloudflare Workers are cost-effective as you only have to pay for the resources (e.g., CPU time, requests) you use. This pricing structure helps you save costs.
Flexibility: Cloudflare Workers give you control over writing logic that can handle your HTTP requests and responses.

In the next section, you will see how Cloudflare Workers compares to AWS Lambda, another serverless provider.

Cloudflare Workers vs. AWS Lambda@Edge

AWS Lambda@Edge is a feature in AWS Lambda that supports running serverless functions at Amazon CloudFront edge locations, bringing computation closer to the user. It is optimized for CDN-based workloads and supports request and response modification, content customization, security features, and smart routing—all without the need for infrastructure management.
However, Cloudflare Workers stand out in certain areas. If you are contemplating which one to use, here’s how they compare:

Feature	Cloudflare Workers	AWS Lambda@edge
Latency	Distributed across wider areas, making it much faster.	Runs in AWS's global edge locations, tied to CloudFront.
Edge Computing	Designed for edge computing, optimized for API gateways, content localization, and personalization.	Optimized for CDN-based workloads within Amazon CloudFront, enabling request and response modifications, content personalization, and security enhancements at the edge.
Deployment	Easier setup with abstracted complexities, better documentation, and deployment tools.	Requires deploying via AWS Lambda with CloudFront triggers, involving IAM roles and permissions.
Cold Starts	Faster cold starts due to small functions and edge capabilities.	Generally slower cold starts, but mitigated by CloudFront caching and optimizations.
Integration	Easily integrates with services like Neon serverless database.	Best suited for AWS services like Amazon S3, DynamoDB, and Cognito; optimized for CloudFront workloads.
Code Size Limit	5MB total package size	1MB per function (after compression), with a max of 50MB uncompressed including dependencies.

Next, let’s explore the benefits of integrating Cloudflare Workers with Neon, how it transforms everything, and how it can make life easier. You'll understand how to integrate your Cloudflare Worker with Neon in a snap and also see how to build a serverless web app in an instant.

Benefits of Integrating Cloudflare Workers with Neon Serverless Database

Neon serverless database is a fully managed open-source Postgres database that decouples the storage and compute components, enabling it to dynamically scale up during high activities and down during idle periods. Neon comes with a serverless driver that makes it super easy to connect Neon to your Cloudflare Workers.

Other reasons why you should consider integrating your Cloudflare Workers with Neon serverless database are:

Low Latency: Cloudflare Workers run on the edge, which means they are close to the user and have low latency. Because Neon’s read replicas and autoscaling capabilities enable efficient fetching of all data, the database queries remain fast for users anywhere, improving the overall app performance.
Cost Efficiency: Both Cloudflare Workers and Neon adjust to workload spikes based on your application's demand, which requires zero infrastructure management. They use a pay-as-you-go model and suspend idle instances to help lower costs. You only pay for what you use.
Simplified Deployment: You don’t need to worry about provisioning or managing servers, as both Cloudflare Workers and Neon are fully serverless.
Security: Cloudflare Workers ship with built-in security features such as DDoS protection, request filtering, and firewalls. On the database side, Neon enables secure access with end-to-end encryption (TLS) and row-level security, simplifying enforcing access control. ## Building a Serverless Web App Using Cloudflare Workers and Neon

Neon serverless databases can be integrated with Cloudflare Workers to process data. Neon provides you with a serverless driver that you can use to connect to your database and then create access data from your database in Cloudflare Workers. Neon’s serverless driver is optimized for edge environments, enabling SQL queries over HTTP or WebSockets. This makes it ideal for Cloudflare Workers, which run in a lightweight, distributed manner without persistent connections.

This section demonstrates how to use the Neon serverless database with Cloudflare Workers to build a serverless web application. This application is a simple Next.js application that fetches brief details about African countries.

Prerequisites
To follow through this tutorial, you need the following:

A Cloudflare account - create a Cloudflare account
A Neon account - create a Neon account
Familiarity with Next.js and TypeScript
Node installed

How The Application Works
The Cloudflare Worker serverless function is created and contains code that accepts and processes requests from the Next.js application. This function serves as your backend code, fetching data from your Neon serverless Postgres database and returning a JSON version of the data as the response. You can then render the response data in your application.

Step 1: Project Setup and Installations
Follow the steps below to set up and install the necessary packages for the application:

Clone the project from GitHub. On the terminal, paste the following code:

git clone https://github.com/Dalu46/my-workers.git && cd my-workers

Open the project in your code editor (preferably VSCode).
Create your first worker by running the following command in the integrated terminal:
```
npm create cloudflare@latest
```
This will attempt to install cloudflare-client-cli (also known as C3 in Cloudflare docs) and wrangler with the following prompts in the image below. Type “./workers” for the first question. This will be the name of your Cloudflare Worker and the folder created when the installation is completed. Select the Hello World example option, click enter, then select the TypeScript option and click enter.
Finally, select No for the last question about deploying your application. You will deploy your application after adding your serverless function code.

Step 2: Create your Neon Serverless Database
Follow the steps below to create a Neon database for the application:

Log in to your Neon account.
Create a new project and a new database, neon-db.
On the left dashboard menu, click on the SQL Editor to add queries to create a new table.

Using Neon’s AI feature, you can generate a simple table using this prompt; you can generate the SQL command from your Neon Console:

“create a table with 3 columns: id | country | Details where id is the unique numeric identifier, country is a string type, and details is a string type. Populate the table with 10 unique fields. Each field has a unique ID, a name of an African country, and a 2-paragraph sentence of that African country”

This will generate a PostgreSQL query command, and after it is done, click the Run button to create the table. The table would have 3 columns: the id, country, and details columns, and it should look like this:

Step 3: Connect your Cloudflare Worker to your Neon Serverless Database
Your database is ready. You can now connect your serverless function to it by following the steps below:

Click the Connect button to retrieve your database URL from your Neon dashboard. This URL should look like this: postgresql://username:FzB6q0lQTTOF@ep-lively-union-42160037-pooler.us-east-2.aws.neon.tech/neon-test-db?sslmode=require
Open the wrangler.json file in the ./workers folder. Add your DATABASE_URL to the variable object to enable your Worker access and connect to your database:

Open your VSCode integrated terminal, run the following command to navigate to the Workers directory, and generate your DATABASE_URL variable type in the worker-configuration.d.ts file.
```
cd workers && npm run cf-typegen
```
Install the @neondatabase/serverless package (this package connects to your Neon serverless database).
```
npm install @neondatabase/serverless
```
Open the index.ts file in the path workers/src/index.ts. This file is your Cloudflare Worker (a.k.a. serverless function). It contains the logic to connect to and fetch your database records from the Neon serverless database and return a JSON response of your database data.

Replace the default content in the index.ts file with the following:

    /**
     * Welcome to Cloudflare Workers! This is your first worker.
     *
     * - Run `npm run dev` in your terminal to start a development server
     * - Open a browser tab at <http://localhost:8787/> to see your worker in action
     * - Run `npm run deploy` to publish your worker
     *
     * Bind resources to your worker in `wrangler.json`. After adding bindings, a type definition for the
     * `Env` object can be regenerated with `npm run cf-typegen`.
     *
     * Learn more at <https://developers.cloudflare.com/workers/>
     */

    import { Client } from '@neondatabase/serverless';

    export default {
            async fetch(request, env, ctx): Promise<Response> {
            // connect to Neon serverless database
                    const client = new Client(env.DATABASE_URL);
                    await client.connect();
                    const { rows } = await client.query('SELECT * FROM african_countries;');
                    console.log(rows);

            // handle CORs error by whitelisting domains
                    const origin = request.headers.get('Origin')
                    const allowedOrigins = [
                            '<http://localhost:5173>',
                            '<http://localhost:5174>',
                            '<http://localhost:5175>',
                            '<http://localhost:3000>',
                    ]

            const corsHeaders = {
                    'Access-Control-Allow-Origin': origin && allowedOrigins.includes(origin) ? origin : '*',
                    'Access-Control-Allow-Credentials': 'true',
                    'Access-Control-Allow-Headers': 'Origin, X-Requested-With, Content-Type, Accept',
                    'Access-Control-Allow-Methods': 'GET,HEAD,PUT,PATCH,POST,DELETE'
            }
                    return new Response(JSON.stringify(rows), {
                            headers: corsHeaders
                    });
            },
    } satisfies ExportedHandler<Env>;

Step 4: Deploy your Cloudflare Worker
You’re ready to deploy your serverless function to your Cloudflare account. Follow the steps below to deploy your Cloudflare Worker:

Run the following command:
```
npx wrangler deploy
```
This will open a new browser window where you must authenticate and authorize using your Cloudflare account. The page will require you to log in if you're not already. Otherwise, click the Allow button to authorize. You should see something like this:
Close the browser tab and retrieve your serverless function URL from your terminal. You can also see your new serverless function (Cloudflare Worker) deployed to your Cloudflare account. Click on workers to view details of your deployed Cloudflare Worker.

Once you have retrieved your serverless function URL, you can send an HTTP request using the fetch() method. The data returned in the response is then used to build the application. In the src/app/details/[id]/page.tsx file, replace the URL with your serverless function URL.

'use client'
import { useEffect, useState } from "react";
import { useParams, useRouter } from "next/navigation"
import styles from "../../page.module.css";
interface AfricanCountry {
  id: number,
  country: string,
  details: string
}
function Details() {
    const [countries, setCountries] = useState<AfricanCountry[]>([]);
    const [isLoading, setIsLoading] = useState<boolean>(true);
    const URL = "https://workers.your_url.workers.dev"; // serverless function URL
    const params = useParams();
    const countryData = countries.find(({id}) => id === Number(params.id));

    const router = useRouter();
    const handleRedirect = () => router.push('/');

    useEffect(() => {
        // fetch countries data from our neon db using our serverless function URL
        (async () => {
            try {
                setIsLoading(true);
                const data = await fetch(URL);
                const _countries = await data.json();
                setCountries(_countries);
            } catch(error) {
                alert('Unable to fetch data');
                if (error instanceof Error) reportError(error.message);
            } finally {
                setIsLoading(false);
            }
        })();
    }, [])
    return (
        <div className={styles.page}>
            {isLoading 
            ? <>
                <span className={styles.loader}></span>
                <p>Fetching details from Neon DB</p>
            </>
            : <>
                <h1 className={styles.header}>{ countryData?.country }</h1>
                <p className={styles.description}>{ countryData?.details }</p>
            </>
            }
            {
                (!countries.length && !isLoading) && <p>No data found</p>
            }
            <button className={styles.btn} type="button" onClick={handleRedirect}>BACK</button>
        </div>
    )
}
export default Details;

To preview the application, run npm run dev. You should be able to try it out at localhost:3000.

This is the final application preview:

Final Thoughts

Cloudflare Workers bring the power of edge computing to serverless development with speed, scalability, and efficiency. When used with serverless databases like Neon, you can build incredibly responsive yet cost-effective apps without managing any infrastructure. Whether building real-time apps, handling API calls, or serving dynamic content, this combination offers performance and agility to scale faster.

Looking to learn more? Look at this Neon tutorial about building web applications using a Neon serverless database with Cloudflare Workers. You can also harness and explore other concepts covered by Cloudflare Workers, such as edge computing, security, and deployments, while keeping in mind the challenges of edge computing, including resource constraints, network reliability issues, security risks, and management complexities.

Write less with this AI-powered code documentation tool

Rojesh Man Shikhrakar — Wed, 05 Mar 2025 13:33:18 +0000

Developers enjoy writing code, solving problems, and shipping products. However, there’s a part that’s not much fun: documenting the code. Writing documentation often feels tedious, leading some developers to delay it until the last minute.

When you finally document everything, you might even forget how exactly you solved the specific issue or why certain parts were connected. You may skip writing comments, assuming other developers will understand your code. A survey shows developers spend 11-50% of their time on code maintenance, including code review, refactoring, and documentation. While tedious and time-consuming, it’s a task that requires you to pause mid-sprint and disrupt your flow.

Why documentation matters

Every experienced developer understands the importance of clear internal or external documentation. An uncommented function can easily be a puzzle for both your future self and other developers. If a code is functional now and will likely remain so in the future, one should write accurate documentation that will serve as a guide that explains:

what you’ve done,
what’s the purpose of the code,
why it’s important,
why certain decisions were made,
how it works, and
how to use the code.

In addition, clear internal documentation definitely improves code readability. It allows you or any other developer to quickly understand, use, or improve the code without getting lost, making code reviews easier.

Documentation is everywhere

Documentation includes a wide range of texts, including user manuals and technical guides, tailored for developers, testers, and end-users. Documentation can be categorized into several types:

User documentation: Written by technical writers, this includes manuals, quick-start guides, tutorials, and frequently asked questions (FAQs) that provide guidance on effectively using the software or product for the end-users.
Technical documentation: This includes architectural diagrams, database schemas, system design documents, API reference documents, and other technical documents that help provide detailed insights into the software’s architecture, design, specifications, and implementation for developers and system administrators.
In-code documentation: Typically includes comments in the code, function, and method descriptions, as well as documentation strings (termed “DocStrings” in Python programming). Several tools generate HTML documentation content from these comments and DocStrings.
API documentation: These documents state an API's form, function, and features. They are typically written by engineers who build the APIs, and the content is consumed by other engineers who implement them.

Note that in certain cases where the primary users are developers, the user documentation doubles as the technical documentation and vice-versa.

Impact of poor or non-existent documentation

Clearly, documentation is important, and failing to consider creating proper documentation can lead to several issues, including the following:

Without technical documentation, code can become challenging for other developers working on the same project, making debugging, resolving issues, and even searching for essential information more time-consuming and complicated. Software engineers would have to go through the entire codebase to understand how a particular component interacts with the rest of the code. This knowledge-gathering process often involves reverse-engineering the code and resorting to trial-and-error methods.
Without comprehensive knowledge of the functionality and dependencies of the code, individual developers may unknowingly introduce conflicting changes in the existing code that may lead to bugs or breakdowns in the later stages.
The wastage of resources and time spent on understanding the poorly documented code delays project timelines, leading to missed deadlines, increased costs, and dissatisfied users.

Good commenting and accurate documentation prevent these issues, clarify the code, help new team members quickly get on board, and ensure everyone consistently understands the codebase.

However, many developers and dev teams still deprioritize documentation practices due to tight project schedules and pressing deadlines under resource constraints.

The documentation process doesn’t have to be as tough as it sounds. In the following sections, we’ll generate various code documentation with Cody, a contextual AI coding assistant, while following best practices for creating practical and accurate content.

Getting started with Cody

Cody provides seamless integration with the code editor of your choice; it can be integrated into Microsoft Visual Studio Code, JetBrain IntelliJ IDEA, PhpStorm, PyCharm, WebStorm, RubyMine, GoLand, Google Android Studio, and NeoVim.

First, create an account and sign up to get free access to Cody. Then, set up your editor.

For Visual Studio Code IDE integration, you can get the Cody extension from the marketplace. Alternatively, you can open the page by clicking View > Extensions in VS code and searching for Cody AI.

When you install Visual Studio for the first time, Cody is usually the last item in the sidebar, where you’ll need to sign in. Here, you should choose the same login method you used when you created an account.

Cody is now integrated into your development workflow, and you can start using it right away.

Generating documentation with Cody

Cody is built upon the latest large language models (LLMs), including Claude 3, GPT-4 Turbo, and Mixtral-8x7B, which are currently the most capable generative models for natural language processing. Cody supports popular programming languages covering various tasks while easily integrating into your favorite development environment. It’s a powerful tool that provides real-time intelligent code suggestions and generates source code with natural language descriptions. It also features a chatbot and a code assistant, which helps you with code comprehension and generation.

Well, how do you use Cody?

Automatic comment generation

Like code auto-completion in the coding process, Cody also automatically suggests documentation when your cursor is at the empty line or end of a statement or when you start writing a comment. Cody works with all programming languages, but this article focuses specifically on Python. When you write code and start with # to begin a comment, Cody can automatically provide intelligent comment suggestions for such repetitive tasks. The highlight indicates the generated content.

import numpy as np
X = np.linspace(-5, 5, 100)  #Generate 100 evenly spaced values between -5 and 5

If you hover over the generated comment, one of the key features of Cody is the tool tip that shows you are getting 1/1 (one of one) generated suggestions. If there are more suggestions, Windows/Linux users can press Alt + ] to move to the next suggestion, press Tab to accept the suggestion, or Ctrl + RightArrow to accept only a word. Similar shortcut keys using Option keys will be available for MacOS.

Generating docstrings for functions

You can generate documentation for a function in your code using Cody. Here’s an example of a code snippet that produces a correlated data point.

def generate_correlated_data(n, corr, mu_x=0, sigma_x=1, mu_y=0, sigma_y=1):
    x = np.random.normal(mu_x, sigma_x, n)
    y = corr * x + np.random.normal(mu_y, sigma_y, n) * np.sqrt(1 - corr**2)
    return x, y

With Cody’s shortcut keys, press Alt + D to generate documentation for the code block. In this case, the docstring for the Python function is a descriptive string written below the function names.


def generate_correlated_data(n, corr, mu_x=0, sigma_x=1, mu_y=0, sigma_y=1):
    """
        Generate a pair of correlated data points with a specified correlation coefficient.

        Args:
            n (int): Number of data points to generate.
            corr (float): Correlation coefficient between x and y data.
            mu_x (float, optional): Mean of x distribution. Defaults to 0.
            sigma_x (float, optional): Standard deviation of x distribution. Defaults to 1.
            mu_y (float, optional): Mean of y distribution. Defaults to 0. 
            sigma_y (float, optional): Standard deviation of y distribution. Defaults to 1.
        Returns:
            tuple: Two 1D NumPy arrays (x, y) of length n with specified correlation.
        """
    x = np.random.normal(mu_x, sigma_x, n)
    y = corr * x + np.random.normal(mu_y, sigma_y, n) * np.sqrt(1 - corr**2)
    return x, y

As you can see, Cody considered multiple lines of code, including the inputs, outputs, and function code, to write a description for the function; the code quality helps for better documentation from the source code.

You can also generate documentation in your cursor based on the simple prompts if you prefer prompt-driven development. On Windows, press Alt + K to open up the Cody Menu and write natural language descriptions for the type and content of documentation you’d like, with additional prompts to guide the style of your prompting.

Here’s another example of documentation generation of a class for a Neural Network using Pytorch.


from torch import nn

class NeuralNet(nn.Module):
"""
  A PyTorch neural network model for image classification tasks.

  The `NeuralNet` class defines a simple feed-forward neural network with two hidden layers, each with 512 units and ReLU activation. The input is flattened from the original image size of 28x28 to a 1D vector of 784 elements, which is then passed through the linear layers. The output layer has 10 units, corresponding to the 10 classes in a typical image classification problem.

  This model can be used as a starting point for training on image datasets like MNIST or CIFAR-10.
  """
    def __init__(self) -> None:
    super().__init__()
    self.flatten = nn.Flatten()
    self.linear_relu = nn.Sequential(
      nn.Linear(28*28, 512),
      nn.ReLU(),
      nn.Linear(512, 512),
      nn.ReLU(),
      nn.Linear(512,10)  # 10 classes
    )
  def forward(self, x):
    x = self.flatten(x)
    logits = self.linear_relu(x)
    return logits

model = NeuralNet().to(device)
print(model)

Cody understands the code context, including the neural network architecture, and writes comprehensive documentation.

Chat feature

An additional feature provided by Cody is the context-aware chat functionality, which assists software developers in the documentation process. Start the chat functionality by pressing Alt + L on Windows and asking questions relevant to the section. Alternatively, you can get started from the Cody plugin menu.

Cody’s chat allows you to add files and symbols as context in your messages; you can type @and then a filename to include a file as context for your prompt. This enables you to use AI as a pair-programming tool, even for writing documentation.

Benefits of using Cody

In simple words, by generating appropriate documentation based on your code, Cody can:

Save time: Cody generates multiple lines of documentation based on the code, which frees up developers’ time to focus on more creative tasks in the development process.
Focus on what matters: Since developers find it cumbersome to write documentation, Cody generates documentation content based on the code context, and the developer focuses on engineering.
Adherence to coding standards: Cody takes care of the convention and style guide when writing the documentation. In the case of Python, you can observe it following PEP-8 Style Guide for Python and PEP-257 Docstring Conventions.
Provide real-time suggestions for improving the quality of your code, whether for the documentation, code snippets, or the entire function.

High-quality documentation is as essential as high-quality code. Cody can be used as a peer programming buddy, for both code and documentation generation.

Getting the most out of Cody

Here are some bonus tips to get the most out of Cody:

Cody works with the scripts as well as Jupyter notebooks in VS code. Thus, it can be helpful for literate programming, which is popular among data scientists, analysts, students, and researchers.

Cody also works in your Markdown files and other text-based documentation files. It can generate content other than code and code documentation, which is useful for general prose required in your project.
- Learning the keyboard shortcut keys can significantly speed up your AI pair programming process. For Windows/Linux users, the following shortcuts might come handy. On Windows:
- Alt + L: Start a new chat with the code assistant, which can help you with code comprehension and code generation.
- Alt + K: Edit code with a natural language description (prompt) about the code
- Alt + D: Document Code
- Alt + C: Open Cody Command Menu to trigger other commands
- You can also use prompt engineering techniques to get better results. You can easily open the prompt and write natural language command prompts, guiding the AI to perform according to your prompt, such as providing more context and expected outcomes.
- Create a custom command for other repeated tasks you’d like to automate in your coding based on custom prompts.
- Open the Command Menu and select Custom Commands > New Custom Command.

Wrapping up

Clear and comprehensive documentation is essential for every developer despite its tedious nature. It ensures code clarity, facilitates collaboration, and minimizes errors in software development. With Cody, an AI-powered coding assistant leveraging advanced large language AI models, developers can automate documentation tasks efficiently.

6 Common Postgres Beginner Mistakes and Best Practices

Dalu46 — Fri, 28 Feb 2025 15:57:58 +0000

“Anyone who has never made a mistake has never tried something new.” - Albert Einstein

Postgres' popularity is steadily increasing. It is the most popular open-source relational database available, and with almost 40 years of development, it is an excellent choice for applications of all sizes. However, starting with Postgres can feel like climbing a mountain, and just like learning anything new, you will undoubtedly make mistakes. Although mistakes are a normal part of the learning experience, they can be time-consuming and difficult to debug. So why not avoid them in the first place?

In this article, you'll learn about the most common mistakes beginners make when starting with Postgres. You'll see why these mistakes happen, how to avoid them, and techniques to help you write queries correctly. You'll also get actionable advice and practical tips to build confidence and develop better habits for database management. Learning from others' experiences can save you valuable time and frustration, so let's get started!

Common Beginner Mistakes

Here are the six common PostgreSQL mistakes beginners should avoid to maintain efficient and secure database environments.

1. Not Understanding What VACUUM Is or When to Use it

Understanding and using VACUUM accurately is important for maintaining a healthy and performant PostgreSQL database. VACUUM is a powerful command that reclaims storage occupied by dead tuples (dead rows). When a vacuum process runs, it marks the space occupied by dead tuples as reusable by other tuples.

When you delete records from a Postgres database table, Postgres does not immediately remove the rows from the database; these are just marked as deleted. The previous version of the record still remains in the data file. This is the same with updates; each update of a row creates a new version of that row. This is called table bloat. These dead spaces are empty rows that occupy unused disk space in the data file and remain present until a vacuum is done.

Many beginners are unaware that they need to run the VACUUM command to clean up dead tuples, which results in bloated databases and slower performance.

It is necessary to run the VACCUM command periodically, especially on frequently updated tables. Regularly reclaiming dead space can improve query performance, reduce disk space usage, decrease disk I/O by reducing table bloat, and ensure your database runs smoothly.

To identify tables requiring vacuuming, run the following code:

SELECT relname, n_dead_tup  
FROM pg_stat_all_tables  
WHERE n_dead_tup > 0;

Note that despite being necessary for a healthy database, VACUUM can have damaging effects when misused. For instance, using the VACUUM FULL command on the production database can lock it for some time.

2. Forgetting to Close Connections

Every time you open a connection, either to fetch or update data, it takes time and utilizes resources like memory and CPU. If these connections are not closed properly after use, they remain open and idle, consuming system resources and eventually running out of the database’s connection limit. This is called a connection leak and can result in errors and downtimes.

One common cause of poor database performance is idle connections. Most developers new to Postgres think that open connections are just idle connections that are not doing anything, but this is incorrect because they’re consuming server resources.

When a connection is not closed, it can trigger an increase in resource consumption, lock tables or rows, and even stop the execution of other queries. This can lead to degradation in database performance over time or even crash your application.

To prevent connection leaks, you must ensure that every connection opened is correctly closed after use. You can do this manually in your code or by using connection pooling tools like PgBouncer, which manage connections efficiently and prevent resource exhaustion.

Here's a sample Python code snippet to properly handle PostgreSQL connections and avoid connection leaks:

import psycopg2

conn = psycopg2.connect("dbname=test user=postgres password=secret")
try:
    cur = conn.cursor()
    cur.execute("SELECT * FROM users")
    print(cur.fetchall())
finally:
    cur.close()
    conn.close()

3. Writing Inefficient Queries

If you’re working with a large number of rows from a big table, you need to be careful while writing queries because it can be tricky. An unoptimized query may scan the entire table or touch significantly more rows than necessary.

Inefficient queries are often the result of poorly written SQL, missing indexes, or a lack of understanding of how PostgreSQL executes queries. When a query hits too many rows, it drives up disk I/O and uses up more CPU and memory (thus decreasing available resources for other queries). Eventually, this will limit the overall performance of your database and your application.

Wrong queries are common among beginners. For example, SELECT * without WHERE or INNER or joining two large tables without proper indexes causes PostgreSQL to scan and process more data than necessary, leading to performance issues.

Here are some useful tips for writing better-optimized queries:

Use Indexes: Indexes are one of the most effective ways to speed up queries. They allow PostgreSQL to quickly locate rows without scanning the entire table. For example, if you frequently query a user table by email, create an index on the email column:

CREATE INDEX idx_users_email ON users(email);

Avoid SELECT *: Fetching all columns when you only need a few can increase the amount of data processed and transferred. This is called the wildcard frenzy. The wildcard might seem enticing, as it displays all data at once, but this approach is not recommended. It’s like going through a lot of things you don’t need to find what you’re looking for, and that’s not efficient.

The best way to query data is to be specific. Rather than returning all of the data from the database and filtering post-query, ask for the data columns you actually need. This makes queries faster and your results clearer.
Rather than writing:

SELECT * FROM users WHERE email = 'test@example.com';

Instead, specify only the columns you need:

SELECT id, name FROM users WHERE email = 'test@example.com';

Use LIMIT: When working with small tables, you may not need to worry about the number of returned rows. However, when working with more oversized tables, LIMIT is beneficial for improving query performance. You can achieve that by using the LIMIT command.

SELECT * FROM users LIMIT 10

4. Forgetting to Add Primary Keys, Impacting Data Integrity

Whenever you create tables in your Postgres database, define primary keys. Without a primary key, the table lacks a unique identifier for each row, making it impossible to enforce data integrity and leading to problems such as duplicate rows. Over time, this can lead to inconsistent data, ruptured relationships, and unreliable query results.

Most novices skip creating a primary key for a table, either because they are unaware of its necessity or they mistakenly think Postgres will provide some unique enforcement on its own. However, this assumption can lead to serious problems, especially as your database grows and becomes more complex.

To avoid these problems, continually assign a primary key for each table. This will help you maintain the integrity of your data, ensure good performance in your queries, and have consistent relationships in your database.

Here are some best practices to prevent data integrity issues emerging from missing primary keys:

Always Define a Primary Key: Include a primary key that uniquely identifies each row when defining a table. For example, in an orders table, you can use order_id as the primary key:

CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT NOT NULL,
order_date DATE NOT NULL
);

Use Composite Keys: Sometimes, using a single column isn’t sufficient to uniquely identify a row. In such cases, use a composite key (a combination of columns) as the primary key. For example, in an order_items table, you might use both order_id and product_id:

CREATE TABLE order_items (
order_id INT NOT NULL,
product_id INT NOT NULL,
quantity INT NOT NULL,
PRIMARY KEY (order_id, product_id)
);

Add Primary Keys to Existing Tables: If you have already created a table without a primary key, you can add one later using the ALTER TABLE command. For example:

ALTER TABLE orders ADD PRIMARY KEY (order_id);

5. Overcomplicating Schema Design

A database schema is any structure that you define around the data. This includes views, tables, relationships, fields, indexes, functions, and other elements. Without any of these, getting lost in a database is easy.

Most beginners are tempted to design a database schema with hundreds of tables, complex relationships, and constraints to guarantee flexibility and scalability. This practice often leads to an overcomplicated schema design that is difficult to maintain and inefficient to query. Overcomplicating schema design usually results in reduced performance and an increased developer learning curve.

When designing your schema, it is essential to maintain a balance between normalization and simplicity. Although data normalization reduces redundancy and improves data integrity, it can also increase complexity. For example, splitting a single logical entity into multiple tables or adding too many foreign key relationships can make queries harder to write and slower to execute.

To avoid complicating the schema too much, consider simplicity and practicality. Start with a base design that fulfills your immediate needs and expand it as your application grows. Keeping your schema clean and intuitive will make it easier to maintain and query your database.

Here are some helpful tips for creating less complex schemas:

Start Simple: Begin with a minimal schema that addresses your immediate needs. Avoid adding tables or columns that you don’t currently require. For example, if you’re building a user table, start with basic fields like id, name, and email:

CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
email TEXT UNIQUE NOT NULL
);

Normalize Thoughtfully: Normalization is important, but don’t overdo it. For example, splitting a user table into user_profiles, user_emails, and user_addresses might seem like a good idea, but it can lead to unnecessary complexity. Instead, keep related data together unless there’s a compelling reason to separate it.
Avoid Overusing Foreign Keys: While foreign keys are essential for maintaining relationships between tables, using them excessively can complicate your schema. For example, creating a separate table for every one-to-many relationship can result in too many joins. Instead, consider embedding related data directly in a table when appropriate.

6. Overlooking the Importance of Backups

Data loss is a nightmare scenario, whether caused by a malicious attack, human error, or a software bug. One of the common mistakes that most developers new to Postgres or working with databases make is overlooking the importance of backups, and the consequences could be devastating.

The most critical aspects of database management are implementing and regularly maintaining a reliable backup strategy. When disaster hits, and it ultimately will, you'll be incredibly grateful that you took the time to plan ahead and back up your valuable data.

There are different ways to backup your data, including using:

pg_dump, a command-line utility for backing up PostgreSQL databases. It can generate logical backups (SQL scripts) or physical backups (binary replicas of the data files). Logical backups are usually more flexible, while physical backups are faster to restore. Here’s an example of how to use it:

# Logical backup (plain SQL script)
pg_dump -U username -h hostname -p port database_name > backup.sql

# Physical backup (directory format)
pg_dump -U username -h hostname -p port -Fc database_name > backup.dump

Third-party tools like Barman or pgBackups provide advanced backup and recovery capabilities for PostgreSQL. These tools make managing backups easier and offer granularity in the backup process.
A managed PostgreSQL service (e.g., Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL, and Neon). One that is a beginner-friendly managed Postgres database is Neon. The following section will discuss how Neon simplifies database management for beginners, especially for backups and schema design.

Tackling Schema Changes, Autoscaling, and Backups the Smart Way

Managing a large database has a few drawbacks: schema upgrades will introduce downtime, backups will be problematic, and scaling will require a lot of hands-on effort. This can lead to insecurity, data loss, downtime, etc.

Neon helps mitigate such issues with a serverless PostgreSQL solution that prioritizes flexibility and resilience. One of the biggest challenges of working with databases is schema changes, especially with growing applications. Traditional database migrations may be risky and cause downtime or inconsistencies. Neon supports schema migration tools such as SQLAlchemy or Alembic, Flyway, Liquibase, and so on. This allows developers to perform structured migrations with minimal or no user interruption.

Another challenge of working with a database is ensuring the database scales efficiently as the workload fluctuates. Neon handles autoscaling to enable your database to withstand workload changes automatically without the need for manual intervention.

Additionally, manually maintaining data and recovering it quickly is a common database challenge. Neon has automatic backups and point-in-time recovery, so if anything goes wrong, like a failing migration or a mistake with a delete, you can quickly restore the data.

There are three main ways to perform backups in Neon:

Point-in-Time Restore (PITR): Point-in-time recovery allows you to restore your database to a specific moment in time. It requires backing up live database files and archiving the Write Ahead Log (WAL), which is the log of all the modifications happening on the database. Neon automatically backs up all of the data with Point-in-Time Restore (PITR), which helps users restore data to any specific point in time. Neon achieves this by retaining a history of all branches without explicitly taking backups. This is crucial for data integrity, guaranteeing your apps’ continuity in case of accidental data deletion and failed login attempts.
Manual Backup Using pg_dump: Like in regular PostgreSQL databases, Neon supports manual backup using pg_dump.
Automated Backups through GitHub Actions: Neon allows for planning automated remote backups (e.g., on Amazon S3) using GitHub Actions to back up sensitive data. You can read more about using GitHub Actions for automated backups here.

Each method serves different needs: PITR is best for quick recovery, pg_dump for full database snapshots, and GitHub Actions for automated external backups.

What’s next?

There are many mistakes that might make you feel discouraged when getting started with Postgres. Don't be; there are several resources and tools available to help you learn more about Postgres. One such tool is Neon, a serverless solution that helps reduce the performance impact of vacuuming, provides autoscaling, offers a branching feature for backups, and many more.

Remember that making mistakes is a major part of the learning process. Don’t be afraid to make mistakes; they help you improve.

Resources

For more information on the tools and concepts used in this guide, refer to the following resources: