Infrastructure & Cloud

Vercel is a hosting platform built around the frontend workflow. A project connects to a Git repository, and every push produces a deployment: production builds from the main branch, and preview builds from every other branch and pull request. The platform is best known for Next.js, the React framework its parent company maintains, but it builds and serves other frameworks and static output too. Deployments run on a global edge network, and build configuration lives in a checked-in file rather than only in a dashboard, so settings travel with the code. Beyond hosting, Vercel sells the surrounding primitives: serverless and edge functions, image optimization, and storage through marketplace partners. Teams that want one vendor for the frontend path consolidate here; teams with long-running backend workloads usually keep those elsewhere.

Neon is a managed Postgres service built on a storage layer that separates compute from data. Because the data layer is copy-on-write, the service can create a full database branch in seconds, and that branch starts as a pointer into the parent's history rather than a physical copy. The practical result is a database workflow that resembles Git. A team can branch production for a preview environment, run migrations against the branch, and throw it away without touching the parent. Point-in-time restore uses the same mechanism, so recovering to a moment before a bad migration does not require replaying a backup. Compute scales to zero when idle, which suits development and preview environments that sit unused most of the day. The tradeoff is cold-start latency on the first query after a suspend, and a connection model that expects a pooler for serverless clients.

Drizzle is a TypeScript ORM built around the idea that the query layer should not hide SQL. Schema is declared in TypeScript, queries are written with a chainable API that maps closely to SQL clauses, and the generated types flow from the schema definition rather than from a separate code generator pass. Migrations are produced by diffing the declared schema against the previous state. The tool emits plain SQL files, which means a migration can be read and edited before it runs. That is a deliberate contrast with ORMs that generate opaque migration steps, and it makes review of schema changes part of the normal pull request. The library supports Postgres, MySQL, SQLite, and the serverless variants of each, and it runs in edge runtimes because it has no dependency on Node-specific APIs. Teams that want an ORM but dislike losing the ability to reason about the emitted SQL tend to land here; teams that want a fully abstracted data layer with a large ecosystem of plugins may prefer a heavier framework.

Turso is a managed SQLite service built on libSQL, an open-source fork of SQLite that adds replication and network access. Each database is a SQLite file, which means the operational model is a file rather than a cluster: small, fast to copy, and trivial to isolate per tenant. Databases can be placed in multiple regions, with one primary accepting writes and read replicas serving queries locally. The embedded replica mode goes further, keeping a local copy inside the application process so reads avoid a network round trip entirely and sync in the background. The appeal is cost and simplicity at high database counts. A multi-tenant product can give every customer their own database without running a fleet of Postgres instances. The constraint is that SQLite is a single-writer system, so write-heavy workloads need the primary and do not benefit from the replica topology.

Hono is a web framework for JavaScript runtimes. The same application code runs on Cloudflare Workers, Deno, Bun, Node.js, and several other environments, because the framework targets the standard Request and Response interfaces rather than a runtime-specific API. The core is deliberately small. Routing is built on a radix tree, middleware composes as a chain, and the framework adds typed helpers for the things an HTTP service needs: parsing input, validating it, setting headers, and returning JSON. Type inference carries path parameters and request bodies through to the handler, so a route can be typed without a separate schema layer. Hono is a good fit for APIs, edge functions, and small services where a full application framework would be excess weight. It is not trying to be a batteries-included framework: there is no built-in ORM, no opinion about the frontend, and no plugin ecosystem of the size a larger framework has accumulated.

Directus is a layer that sits on top of an existing SQL database rather than replacing it. Point it at a database and it introspects the schema, then generates a REST and GraphQL API plus an admin application for the tables it finds. The database remains the source of truth. That inversion is the main difference from a conventional CMS. Content is not locked in an application-specific structure: the tables are ordinary SQL tables, readable by other tools and migrations. Custom fields, relations, and permissions are configured in Directus and stored in the same database, so a DBA can still work with the schema directly. The product is open source and self-hostable, with a paid cloud offering. It fits teams that already have a database and want an admin interface and API over it without migrating. It is a weaker fit when the schema is expected to change constantly, since the database is the contract.

Railway is an application hosting platform that takes a repository and runs it. The workflow is deliberately short: connect a Git provider, pick a repository, and Railway detects the language, installs dependencies, builds, and starts the process. Databases and other services are added as separate components in the same project. The product's model is a project containing services. A service can be a repository deployment, a database from a template, or a container image. Services reference each other through generated environment variables, so a web service gets a database connection string without a manual copy step. Configuration is optional rather than required. A repository with no build file still deploys through language detection, and a repository that needs control can add a config file to override the build command, the start command, or the health check. The platform publishes usage-based pricing, a status page, and a changelog, which is what makes the operational claims checkable.

Clerk is an authentication service that ships prebuilt user interface components alongside the underlying session infrastructure. The pitch is that sign-in, sign-up, profile management, and organization switching should not be a multi-week build for every application. The integration is a set of components rather than a form the developer assembles. A React application mounts a provider, and the sign-in and user-profile surfaces render with the application's styling. Underneath, Clerk manages sessions, password hashing, multi-factor flows, and social providers. Beyond basic authentication, Clerk models organizations: a user can belong to several organizations with different roles, and the session carries the active organization so application code can authorize against it. The service publishes documentation, a changelog, and a status page, and the SDKs are open source even though the service itself is not.

Grafana is a visualization and dashboarding platform. It queries data sources - Prometheus, Loki, PostgreSQL, and many others - and renders the results as panels arranged on a dashboard. The product's longevity comes from that separation: Grafana does not store most of the data it displays, it queries systems that do. The query model is per-panel. A panel selects a data source, runs a query, and applies a visualization. Because data sources are pluggable, the same dashboard tool works across a metrics database, a log store, and a SQL database without moving data between them. Alerting is built on the same queries. A rule evaluates a query on a schedule and fires when a condition holds, which means an alert and the dashboard panel that motivated it are defined in the same language. The core is open source and self-hostable, and the hosted service is the commercial layer.

Ethereum is a public blockchain whose distinguishing feature is that it executes general-purpose programs. A smart contract is code deployed to the network, and any account can call it, which turns the chain from a payments ledger into a platform other applications are built on. The network is maintained by validators who stake ether and are rewarded for proposing and attesting to blocks, with penalties for misbehaviour. Because every node verifies every transaction, the state of the chain is agreed without a central operator. Fees are paid in ether and scale with the computational work a transaction requires. The tradeoffs are the reason alternative chains exist. Throughput is limited by the requirement that every node process every transaction, so fees rise when demand is high. Contracts are immutable once deployed unless written to be upgradeable, which means a bug can be permanent. And the account model puts the burden of key management on the user, where a lost key means lost funds.

Payload is a content management system that installs into an existing application rather than running beside it. Instead of a separate admin service reached over an API, Payload mounts its admin panel and its API inside a Next.js or Express application, sharing the same database and the same deployment. The configuration is code. Collections, fields, access control, and hooks are declared in TypeScript files, which means the content model is versioned with the application and can be type-checked. The generated admin panel reflects that configuration. Because it mounts into the application, the deployment story is the application's deployment story. There is no second service to host, and the database is the one the application already uses. The source is published, and the product can be self-hosted, which is the norm for this category.

n8n is a workflow automation tool that connects services through a visual node editor. A workflow is a graph: a trigger node starts it, and subsequent nodes call APIs, transform data, or branch on conditions. The product sits between two categories. It is more visual than writing an integration script, and more code-friendly than a consumer automation tool: nodes can include JavaScript expressions, and a code node can run arbitrary logic inside the workflow. That combination is what lets it handle a transformation that a purely visual builder cannot express. n8n is published as source and can be self-hosted, which matters for teams that need automation to run inside their own network. The hosted cloud is the commercial layer. The self-hosted deployment is the same core, so a workflow can move between them.