标签：#Serverless

If your files already live in Amazon S3, the pitch for storage that branches with your database is appealing but the word "migration" makes it sound like a project. It mostly is not. Neon's object storage speaks the S3 API, so the code you already wrote, the AWS SDK calls and presigned URLs, keeps working. What changes is how you point the client and where the bucket comes from, and that is a small, mechanical diff. The actual data move is a copy loop you can run once. The one thing to do up front is confirm the object operations your app actually relies on: the demo here exercises PutObject , GetObject , listing, and presigned URLs, and I flag the S3 features you should check for yourself further down. This post is the practical version: what stays identical, the exact config that changes, a script to copy the objects across, and an honest list of the S3 features that do not have an equivalent so you know what to check before you commit. The repo with the working client is at the end. TL;DR Neon object storage is S3-compatible. Your @aws-sdk/client-s3 code for the common operations, PutObject , GetObject , getSignedUrl , listing, works unchanged (these are what the demo verifies). Confirm anything beyond that, like multipart for large objects, against the current preview. The diff is the client config: point endpoint at the Neon storage endpoint, pin region: 'us-east-2' , set forcePathStyle: true . The bucket is declared in neon.ts instead of created in the console, and credentials are injected per branch. Move the data with a list-and-copy loop between two S3 clients (source AWS, destination Neon). What does not carry over: S3 bucket policies, event notifications and Lambda triggers, storage classes and Glacier transitions, and cross-region replication. Object CRUD and presigning do. The payoff is everything else in this series: once the files are on Neon, they branch with your database. Prerequisites An existing S3 bucket and credentials that can read it A Neon p

If your app stores files and you want real preview environments, you eventually hit the same wall: each preview needs its own storage, so you start provisioning a bucket per environment. That sounds cheap until you write it down. For every ephemeral environment you create a bucket, attach a policy, mint an IAM role or access keys, set CORS, add a lifecycle rule so it eventually cleans up, wire the credentials into the preview's config, and register a teardown step for when the PR closes. Then you find the orphaned buckets the teardown missed, months later, still billing. The reason this is painful is that the bucket is a separate resource from the database, so it needs its own lifecycle. Neon collapses that: the bucket is declared as part of the branch, so it is created and destroyed with the branch and needs no per-environment provisioning at all. This post compares the two approaches and shows the branch version working with no bucket-management code in sight. The repo is at the end. TL;DR Isolated storage per preview usually means provisioning a bucket per environment: policy, IAM, CORS, lifecycle, credential wiring, teardown. It is slow, it drifts, and it leaves orphaned buckets that keep costing money. On Neon the bucket is declared once in neon.ts . Creating a branch brings the bucket (with a copy-on-write copy of the files) and injects scoped credentials; deleting the branch removes it. There is no per-environment bucket to create, no IAM role to mint, and nothing to orphan. Copy-on-write means fifty preview buckets do not cost fifty times the storage, only what each one changes. Prerequisites A Neon project on the platform preview (object storage, us-east-2 ) The Neon CLI, and a CI system that opens/closes preview environments Familiarity with S3 buckets and IAM if you have done the manual version The per-environment bucket, written out Here is what "just give the preview its own bucket" actually expands to, per environment: Create a bucket with a unique nam

The naive way to accept file uploads is to POST them to your API, let the server read the bytes, and write them to object storage. It works until the files get large or the traffic gets real. Now every upload crosses your infrastructure twice, once from the client to your server and once from your server to storage, and your server holds the whole file in memory or on disk while it does. On a serverless function it is worse, because functions have request-size and duration limits that a big upload runs straight into. Presigned URLs are the standard fix, and they predate serverless by a decade. Your server does not move the bytes; it hands the client a short-lived, pre-authorized URL and the client uploads directly to object storage. The server only issues permission and records metadata. On a Neon Function this is the same AWS S3 SDK you already use, pointed at the branch's storage endpoint. This post builds it and tests the whole round trip. The repo is at the end. TL;DR Proxying uploads through a function sends the bytes across it, burning bandwidth and memory and hitting request-size limits. A presigned URL is a time-limited, pre-authorized link to one object key. The client PUTs the bytes straight to storage; the function never touches them. On Neon Functions you generate it with getSignedUrl from @aws-sdk/s3-request-presigner , the same code as any S3-compatible store. I tested the full flow: presign, the client PUT straight to storage returned 200 , a metadata record was saved, and downloading the object returned the exact bytes. One gotcha to pin: the injected AWS_REGION is the storage-cell host, not a region, so set region: 'us-east-2' on the client. Prerequisites A Neon project on the platform preview with a declared bucket (object storage, us-east-2 ) The AWS SDK: @aws-sdk/client-s3 and @aws-sdk/s3-request-presigner Familiarity with S3-style object storage and HTTP PUT Why not just proxy the upload Sending the file through the function has three costs that

As software engineers, our default setting is often to over-engineer. When tasked with building a web utility—such as an image sorter or a layout planner—our minds immediately jump to designing a complete backend ecosystem. We start sketching out PostgreSQL schemas, configuring AWS S3 bucket lifecycles for user uploads, setting up Redis caches, and writing authentication middleware. While this architecture is robust, it introduces massive overhead: Financial Cost: Database queries and S3 egress fees scale with your user base. Maintenance Burden: Keeping server packages updated, managing API endpoints, and handling database backups. Legal Compliance: Storing user-uploaded files means dealing with GDPR, CCPA, and data privacy regulations. When I started building Rankly, an online Tier List Maker, I challenged myself to eliminate the backend entirely. I wanted to build a high-performance web tool capable of scale, with a server hosting bill of exactly $0/month, while giving users complete privacy. Here is a technical deep dive into how we built a stateless, zero-database frontend architecture that processes complex image grids entirely client-side. Traditional tier list tools follow a client-server-client round-trip pattern: User uploads images -> Sent to server. Server saves to S3 -> Returns public URLs. User drags/drops -> State saved to database via JSON payload. Export -> Server-side headless browser (like Puppeteer) renders the page and takes a screenshot -> Sent back to user. This pattern is slow and highly resource-intensive. Rankly completely bypasses the server by implementing an entirely local-first rendering pipeline. [Local File Upload/Drag] │ ▼ (FileReader API / Object URL) [Local Memory State (React/State)] ───► [Interactive Grid UI (Tailwind)] │ ▼ (HTML5 Canvas Synthesis) [Local Client-Side Render] ───► [High-Res PNG Download] To let users use their own images without uploading them to a remote server, we utilize the HTML5 File API. When a user drags and

Canonical URL: https://blog.1001020.xyz/ Suggested cover image: use a recent image from https://blog.1001020.xyz/gallery I have been building a small publishing system called 1001020 , a serverless blog and AI gallery running on Cloudflare Workers. The live site is here: 1001020 — AI Gallery & Cloudflare Experiments The goal was not to build another static blog generator. I wanted something that could publish articles, serve an image gallery, manage uploaded assets, expose structured sitemaps, and stay operational without a traditional server. The basic architecture The whole public site runs on Cloudflare Workers. Articles, settings, comments, gallery metadata, and telemetry live in Cloudflare KV. Managed images are stored in R2 and served through a dedicated image domain. The main pieces are: Cloudflare Workers for request routing and rendering Cloudflare KV for article and site metadata Cloudflare R2 for managed image uploads A theme system for different frontend layouts XML sitemap and image sitemap generation A small local AI drafting tool for preparing and publishing content The gallery is a first-class part of the site, not just a media folder. You can browse it here: AI Gallery on 1001020 Why Workers instead of a conventional backend? For this project, Workers are a good fit because the workload is mostly request routing, HTML generation, metadata reads, and small API writes. A conventional server would work, but it would add deployment and maintenance overhead that I did not need. Cloudflare Workers also make it easy to keep the app close to the edge while still handling dynamic behavior. The blog can render pages server-side, expose APIs, and support admin operations without a separate Node or container deployment. KV as the content store The project stores persistent content in KV using explicit keys for articles, gallery records, settings, telemetry, comments, newsletter subscribers, and other small datasets. This shape works well for a personal publishi

Elena van Engelen discusses how to eliminate serverless vendor lock-in without sacrificing native cloud capabilities. She explains how to structure FaaS applications using Clean Architecture, Spring Cloud Function, and Gradle modules to isolate business logic. Finally, she shares a live demo deploying portable Kotlin services across AWS and Azure using Terraform CDK for multi-cloud IaC. By Elena van Engelen

I wanted two things: short links under my own brand (every link I share points traffic back to my site ), and a real excuse to run a complete system on the edge — DNS, distributed compute, storage, auth and a dashboard — in production, at zero infrastructure cost. The result is flino.link : a shortener that responds in under 10 ms from 300+ locations, runs entirely on Cloudflare's free tier, and whose only expense is the domain: $4.68 a year. This post covers the design decisions, which is where the interesting parts are. The architecture in 30 seconds A single Cloudflare Worker serves the whole domain: GET /<slug> — the hot path. One read from Workers KV (globally replicated) and a 302 redirect. Nothing else touches that path. /api/links — a REST API with Bearer auth to create, list and delete links. /admin — a single-page dashboard served as inline HTML from the Worker itself. No framework, no build step. A Durable Object with embedded SQLite keeps per-slug click counts. No servers, no containers, no database to manage. The whole Worker is three TypeScript files and zero runtime dependencies. Why a dedicated domain? My first idea was to hang the shortener off a route on flino.dev . Bad idea: shorteners attract abuse — spam, phishing — and their domains sooner or later end up on blocklists. If that happens, I don't want it dragging my main domain down with it. A separate domain isolates that reputation risk completely, and a short .link costs less than a coffee per year. KV for links, a Durable Object for counters This is the central design decision. Workers KV is perfect for a shortener's access pattern — read-heavy, write-light, reads served from the edge — but its writes are eventually consistent : two concurrent increments in different datacenters would clobber each other. For counting clicks, it's useless. A Durable Object solves exactly that: it's a single global instance with transactional SQLite storage. Every increment, no matter which datacenter it comes

Introduction Serverless computing has become a buzzword in cloud architecture. But like any tool, it has sweet spots and sharp edges. After building and maintaining several serverless applications, I've learned where it shines and where it creates headaches. This article shares those lessons. When Serverless Helps 1. Event-Driven Workloads Serverless excels when your code runs in response to events: file uploads, database changes, HTTP requests. The pay-per-execution model means you don't pay for idle time. // AWS Lambda handler for image resizing exports . handler = async ( event ) => { const bucket = event . Records [ 0 ]. s3 . bucket . name ; const key = event . Records [ 0 ]. s3 . object . key ; // resize and save return { statusCode : 200 }; }; 2. Variable or Unpredictable Traffic If your app has occasional spikes (e.g., a marketing campaign), serverless auto-scales instantly. No need to provision for peak load. 3. Rapid Prototyping and MVPs You can deploy a fully functional API in minutes without managing servers. This accelerates feedback loops. 4. Microservices and Glue Code Serverless functions are perfect for small, single-purpose services that connect other services (e.g., processing webhooks, data transformation). When Serverless Hurts 1. Long-Running Processes Most providers have a maximum execution timeout (e.g., 15 minutes for AWS Lambda). Batch processing or video transcoding may hit this limit. # This will timeout if processing takes > 15 minutes def handler ( event , context ): process_large_file ( event [ ' file ' ]) return { ' done ' : True } 2. Cold Starts After a period of inactivity, the first request may have a delay of several seconds. This is detrimental for latency-sensitive applications like synchronous APIs. 3. Stateful Applications Serverless is stateless by design. If you need persistent connections (e.g., WebSockets) or local state, you'll need additional services like Redis or DynamoDB, adding complexity. 4. High, Steady Load If your

If you've ever hit deploy on AWS Fargate and watched the task sit in PENDING forever, this one's for you. I ran a small experiment with Seekable OCI (SOCI) the AWS thing that promises to fix Fargate cold starts. This article is what I learned. The good, the boring, and the "wait, that didn't work?" bits. You'll walk away knowing what SOCI is, whether you should bother setting it up, and what real numbers look like! Prerequisites ✅ You've deployed something on AWS Fargate before. You know what a Docker image is. You have an AWS account you're OK spending ~$5 on. That's it. 🤔 The Problem Fargate is great. Push a container, get a running task. No nodes to manage! Until you use a big image. Every Fargate task pulls the whole image before starting. No shared cache. No head start. If your image is 3 GB, your task waits for 3 GB to download. Every time. Every task. For an ML model or a heavy Java service, cold start becomes minutes, not seconds. Two stats made me actually care about this: 76% of container startup time is just downloading the image. Only 6.4% of that image data is needed to actually start the app. So you're pulling 100% to use 6.4%. And it costs you 76% of your startup budget doing it. That's ridiculous!! This isn't a Fargate-only problem, by the way. It's a container problem. But Fargate hurts more because you can't cache anything at the host level. I presented this talk at AWS Community Days Bangalore 2026 💡 What is SOCI? SOCI stands for Seekable OCI . Simple idea: Instead of downloading the whole image before starting the container, download only the parts the app needs right now. Everything else gets pulled lazily, in the background, while the app is already running. The way it works: You push your image to ECR like normal. A separate tool builds an index a byte-level map of what's in each layer. Fargate reads the index at startup and only fetches the bytes it actually needs to boot the process. As the app tries to read more files, Fargate fetches those

I've built a lot of voice integrations. Every single one needed a deployment whose only job was to talk to the Sinch API: receive the callback, translate it into SVAML or a Conversation API call, hand off to the rest of the application. Not the interesting part. Just the piece that has to exist because your code and Sinch's network live in different places, with a round trip between them on every call event. Sinch Functions moves that piece into the network itself. Your voice and messaging handlers run on the same infrastructure that's already carrying your calls and messages, right where the callbacks originate. This isn't a general-purpose Lambda replacement: the rest of your application, and any compute that isn't glue against Sinch's APIs, stays exactly where it is, whether that's AWS, Azure, or your own infrastructure. Your order lookup, your database writes, your actual business logic: still on Lambda or wherever you already have it. Functions is specifically for the code that exists only to bridge your app and the Sinch network, not a place to run your whole system. I've been trying it out and this post walks through getting set up, writing a basic voice function, and deploying it. Pricing is usage-based and separate from your Voice and Conversation usage: $0.10 per compute-hour (first hour free each month), $0.05 per GB-month of storage (first 0.1 GB free), $0.05 to $0.15 per GB-month for the database depending on tier (first 0.1 GB free), and $5.00 per month per function if you want it kept always-on instead of scaling to zero. These are the current Standard rates from your project's Billing Overview in the Sinch dashboard; treat them as a snapshot, not a guarantee, given the Alpha status below. Sinch Functions is listed as Alpha in the Sinch Build dashboard. Expect the CLI, runtime APIs, pricing, and this walkthrough itself to change before general availability. Treat it as something to experiment with, not something to put in front of production traffic y

If you are a fellow blogger or web developer looking to build a high-performance, developer-friendly,...

I've been working in software for more than 15 years. This is the first piece I've decided to write about the job. I picked this topic because it was a small, real problem that cost me time more than once, until I finally stopped and fixed it properly. Quick disclaimer: this isn't distributed tracing or multi-service observability. It's a targeted fix for one specific problem: correlating logs within a single Step Function execution. If your scenario is different, the problem takes a different shape. What matters here is the reasoning, not the recipe. Quick context for anyone who doesn't work with serverless: AWS Step Functions is an orchestration service. You design a workflow as a state machine (JSON), and each state usually triggers an AWS Lambda (a function that runs on demand, no server to manage). In my case, a request kicks off a state machine execution that passes through several Lambdas in sequence: some do validation, others call external services, and one waits on a callback response before moving on. The fix turned out to be simpler than it sounds: a field Step Functions already offered for free, and I just wasn't using it. A request was processed 120 days ago. The customer calls: "Did you receive my request? I never heard back." You open the AWS Console. The Step Functions execution is already gone. Execution history only sticks around for 90 days, and even within that window, finding one specific execution among thousands is already a hassle. That leaves CloudWatch, with logs from every Lambda in the pipeline. You have one piece of data: the case ID. But every Lambda logged its own way: no standard, no correlation between them. To reconstruct what happened, you have to open each function's logs in the order the workflow probably ran, and piece it together by hand. It wasn't the error itself that hurt. It was the time lost just organizing the logs before you could actually start investigating. The Chaos The pipeline wasn't huge, but it wasn't trivial ei

#NebiusServerlessChallenge Live dashboard: Myth-Busting Quantitative Terminal · Live endpoint: /predict on Nebius Serverless · Code: github.com/KoralZakai/stocksPredictionAfterTweet Everyone on a trading desk knows the story. He tweeted about Intel, and the stock ran for months. He posts about Iran, oil spikes. The anecdotes are vivid, specific, and everybody has one. While the prevailing myth suggests that Trump's tweets drive market movements, my research — built on an analysis of 78,130 posts, with Llama-3.3-70B reading every market-relevant tweet — reveals a more nuanced reality. The findings demonstrate that the market tends to price in significant events long before the tweet is even posted. This indicates a case of reverse causality, where the market dictates Trump's narrative, rather than the other way around. He isn't moving the market; he is simply riding the wave of established trends. Forward — the direction you could trade — the signal is a coin flip, and I can show that with pre-registered tests rather than vibes: 0 of 63 cells survive correction. Getting to that answer honestly was the hard part. Seven times this pipeline produced a beautiful, publishable, completely false positive — each one looking exactly like the discovery the anecdotes promise. Those seven are the engineering content of this post. The setup Data. 78,130 public posts; 8,317 in the study window (2025-01-01 → 2026-07-06). Daily OHLCV bars for 62 tickers, committed to the repo. Public data only — a stranger can re-run every number without a single private key. The model. meta-llama/Llama-3.3-70B-Instruct on Nebius AI Studio , zero-shot, reading only the tweet text : what is this post about, which instruments does it touch, and which way does each one go. 476 tweets, 1,296 instrument calls. No fine-tuning — the question is whether the text carries signal, and a fine-tune would smuggle the outcome into the answer. The architecture. Nebius Serverless AI Jobs run the batch research pipel

I've been building AI agents for a while now, and streaming responses to a UI has always been the painful part. In previous projects I tried API Gateway streaming, Lambda response streaming, and even AppSync Events via an agent tool call to notify the UI. I also looked at adding my own WebSocket API through API Gateway, which requires managing $connect , $disconnect , and $default routes, storing connection IDs in DynamoDB, and posting messages back through @connections . All of these approaches felt like too much ceremony for what should be simple. That's when I found that AgentCore has built-in WebSocket support. The browser can just connect directly to the agent. No middleman. I built WearCast to demonstrate this functionality. This is an AI agent that helps you pick out what to where based on the weather. I've found this very helpfu when packing for a trip. The code for this application is public and you can find the full implementation on this GitHub repo . The problem with the traditional approach We usually build app applications as we do REST APIs User → REST API → Lambda → AI Service → Lambda → REST API → User Every message makes a round trip through multiple intermediaries. The response waits until the entire generation is complete, and then it all comes back at once. For a chat interface, this feels sluggish. Users stare at a spinner while the model generates hundreds of tokens they could already be reading. Even if you add Server-Sent Events or long-polling, you're still stitching together a real-time experience on top of infrastructure that seemed like overkill. I wanted something better. The architecture Here's what I ended up with: ┌─────────────┐ ┌──────────────────┐ │ React UI │─── JWT ─▶│ API Gateway + │──▶ Lambda (presigned URL) │ (Cognito) │ │ Cognito Auth │ └──────┬──────┘ └──────────────────┘ │ │ WebSocket (SigV4 presigned URL) │ ← No middleman! Direct connection → ▼ ┌──────────────────────────────────┐ ┌────────────────────┐ │ AgentCore Runtim

Database branching is one of the best ideas serverless Postgres brought to the mainstream. Fork the database at a point in time, get an isolated copy with all the data, run something risky against it, throw it away. It made preview databases and safe migrations feel routine. But a real application is not just a database. It is a database, plus the files it stores in object storage, plus the backend code that serves it, plus, increasingly, the model and gateway config it calls for AI. When you branch only the database, those other three stay shared. Your "branch" points at the same S3 bucket, the same deployed backend, and the same AI configuration as everything else. So it is half a copy, and the half it leaves out is where a lot of the interesting bugs and the scary migrations live. Neon's platform preview changes what a branch contains. A branch now forks the database and its data, the object storage and its files, the functions that run your backend, and the AI gateway config, all at the same point in time, all isolated. A branch stops being a database copy and becomes a whole environment. To make sure that is a real claim and not a diagram, I took a full-stack project, branched it, and checked every layer. Here is what happened. TL;DR Elsewhere, "branch" means the database only. Object storage, backend deploys, and AI config stay shared, so you bolt on scripts to fake per-branch versions of them. A Neon branch forks all four together: Postgres + data, object storage + files, functions (each branch gets its own URL), and the AI gateway. I proved it: branched a project with a DB, a bucket of files, a function, and the gateway. The branch came up with a copy of the rows, a copy of the files on its own storage endpoint, its own function URL, and the gateway. A write to the branch left main untouched, and deleting the branch removed all of it. That makes a branch a real environment: true preview stacks, whole-state bug reproduction, and disposable sandboxes for agent

At re:Invent 2025, AWS announced Lambda Durable Functions . The feature introduces a checkpoint/replay mechanism that allows Lambda executions to run for up to one year, automatically recovering from interruptions by replaying from the last checkpoint. Lambda's 15-minute timeout is not a bug or a limitation to work around. It is a deliberate design choice that encourages keeping functions simple and focused, and in most cases it does its job well. When a function needs more time, the usual approach is fanout : split the work into smaller Lambdas, orchestrate them, move on. I have done it many times and it works perfectly fine. But a few days ago I was developing a new Lambda function for a pipeline orchestrated by Step Functions, and the execution time exceeded 15 minutes. I could have done the usual split, but durable functions had just come out and I wanted to try them. At first glance, durable functions can look like a replacement for Step Functions. Both services manage multi-step workflows , both offer checkpointing and automatic recovery , and both let you coordinate complex operations. For certain use cases, that might actually be the case: if your entire workflow lives inside a single Lambda, durable functions can handle everything on their own without an external orchestrator. But the AWS documentation actually suggests using them together. The "Hybrid architectures" section says it explicitly: many applications benefit from combining the two services, using durable functions for application-level logic within Lambda and Step Functions to coordinate the high-level workflow across multiple AWS services. My case fit that description, and more than a perfect architectural match, I wanted to learn how the two services actually work together and form my own opinion on when the hybrid approach makes sense. I figured integrating the two would be a small change. It was my first time working with the durable execution SDK, and since the code I write is mostly infras

I built a tool that answers one question: when a website won't load, is it your connection or the site? It runs two checks in parallel — measures your own line in the browser (latency + a 1 MiB download), and probes the target from Cloudflare's edge — then returns one of four verdicts: it's not you, it's you, it's both, or all clear. Demo: https://itsnotyou.site The interesting part isn't the tool, it's that the whole thing — app, ~120 monitored sites with 24h history, SSR status pages, share cards, outage alerts — runs for $0/month plus domains. The one thing that wanted to cost money Everything fit the Workers free plan except a background monitor probing ~120 sites on a tight cadence. As a Worker cron that's ~120 subrequests/run and, done naively, thousands of KV writes/day — which pushes you onto Workers Paid. The real ceiling is KV: 1,000 writes/day. So I split it. The user-facing test stays on Cloudflare — the edge probe still measures from the colo nearest the user, which is the point of edge. But the background sweep moved to a cheap VPS I already had: it probes the roster on a systemd timer and pushes results back into KV over the REST API. Staying under 1,000 KV writes/day One KV key, not key-per-site. All ~120 statuses live in a single blob. Key-per-site at sweep cadence would be millions of writes/month; a single blob is one write per sweep. Widen the cadence. I started at 2 min = 720 writes/day. Cloudflare emailed that I'd hit 50% of the daily limit (the sweep wasn't the only writer). I went to 3 min = 480/day, leaving headroom for share cards and the notify list. Move the hot counter off KV. The anonymous "tests today" counter was the sneaky risk — a traffic spike could exhaust the write budget and stall the status sweep, the one thing you can't let happen. It went to Analytics Engine instead (free, uncapped, separate budget). Now no amount of user traffic can starve the monitor. Reader and writer share code so their rules never drift: the streak/histo

When Neon became the official database partner of DEV Community, I was already a user. But the partnership made me look closer at why I chose Neon — and whether those reasons apply to other AI developers. They do. Here's why Neon is the ideal database for AI applications in 2026. The Problem: AI Apps Have Unique Database Needs AI applications have database requirements that traditional web apps don't: High write volume — every AI request generates logs, metrics, and cost data Variable load — traffic spikes when a model goes viral, then drops to zero Schema evolution — you're constantly adding models, routing rules, and analytics tables Dev/prod parity — you need to test routing changes against real production data Edge compatibility — AI APIs need sub-100ms response times globally Traditional PostgreSQL (RDS, Aurora) struggles with all five. Neon was built for them. Feature 1: Database Branching (The Game-Changer) This is Neon's killer feature. It works like git branch but for your entire database: # Create a branch from production neon branches create --parent main --name test-deepseek-v31 # Get a connection string for the branch neon connection-string test-deepseek-v31 # → postgresql://...@ep-test-deepseek...neon.tech/neondb # Run migrations on the branch npx prisma db push --url $BRANCH_URL # Test your new routing algorithm against REAL data # (the branch is a copy-on-write clone of production) # When tests pass, merge neon branches merge test-deepseek-v31 Why This Matters for AI Apps When I added DeepSeek V3.1 to my model pool, I needed to test: Would the new model break existing routing rules? Would the cost calculations be correct? Would the latency meet my SLA? With traditional PostgreSQL, testing against real data meant either: Copying production to a staging DB (hours, $$) Testing with synthetic data (unreliable) With Neon branching, I branched, tested in 30 seconds, and merged. Zero downtime, zero risk. Feature 2: Scale-to-Zero (Cost Optimization) Neon's c

Your order-processing Lambda starts sending duplicate confirmation emails. Not always — maybe one order in twenty. CloudWatch shows more invocations than messages published. The function code hasn't changed in weeks. What changed is that someone added a fraud check that pushed processing time from 25 seconds to around 45, and your SQS queue is still running the default 30-second visibility timeout. That combination is the whole bug. When a Lambda pulls a message from SQS, the message isn't deleted — it's hidden for the duration of the visibility timeout. If the function is still working when that window closes, SQS assumes the consumer died and hands the same message to another invocation. Now two Lambdas are processing the same order, both will "succeed," and both will send the email. Nothing errors. Nothing retries. There is no log line that says "this message was delivered twice because your timeouts are misconfigured." Infrawise ( npm ) flags this exact mismatch as a high-severity finding before it costs you an afternoon of staring at idempotency-free handler code. This post walks through why the bug is so hard to see, how the detection works, and how to keep an AI assistant from reintroducing it. Why you never catch this one yourself Three things make this misconfiguration nearly invisible: It passes every test. In local tests and staging, your handler processes a synthetic message in two seconds. The 30-second visibility window never comes close to expiring. The bug only exists under production conditions — real payload sizes, real downstream latency, cold starts stacking on top of slow dependencies. The defaults set the trap. SQS queues default to a 30-second visibility timeout. Lambda functions routinely get their timeout bumped to 60, 120, or 900 seconds as they grow. Nobody bumps the queue at the same time, because the two settings live in different consoles, different IaC resources, and usually different pull requests. The failure signature points elsewhe

Every developer has that one project. The passion build that sits in the back of your mind for months—or even years—before you finally sit down, crack your knuckles, and make it a reality. For me, that project was building a modern, open-access bilingual digital lexicon bridging English and Assamese: AssameseDictionary.org . While it started as a personal milestone dream, it quickly turned into a massive data engineering and architecture challenge. Here is how I tackled parsing a massive vocabulary database and serving it globally with near-zero latency. 🏗️ The Core Challenge: Scale vs. Speed A dictionary isn't like a standard SaaS app or landing page. It lives and dies by its database depth. To make this a truly definitive tool, I compiled, cleaned, and programmatically validated an extensive vocabulary index mapping over 293,000 words . The dataset doesn't just hold simple translations; it maps complex bidirectional lookups, phonetic transliterations, advanced English definitions, context usage examples, and cross-linked synonym tokens. If I threw this massive dataset into a traditional relational database hooked up to a standard server setup, I ran into immediate roadblocks: Latency: Heavy search queries on a dataset this size can cause noticeable lag. Cost/Overhead: Maintaining and scaling database servers for unpredictable public traffic gets expensive fast. I wanted the search utility to snap back instantly. To achieve that, I had to ditch traditional server paradigms entirely. ⚡ The Architecture: Serverless Edge Caching To keep things ultra-lightweight, highly cost-effective, and blazing fast, I built the platform around an edge-computing topology: The Runtime: I offloaded the backend logic entirely to Cloudflare Workers . Instead of routing traffic to a centralized origin server, queries are intercepted and executed at serverless edge locations physically closest to the user. The Data Layer: Instead of an active SQL database bottleneck, I mapped the data mat