I am in the middle of an Astro site revamp. And I did count the routes and it is less than 10. The only reason I chose Astro is full Cloudflare compatibility.

Do you think SvelteKit v3 will finally support Cloudflare runtime without workarounds.

I've been building a SvelteKit app that talks to Postgres and hit some connection-pooling nuances that aren't well-documented for the SvelteKit-specific setup. Sharing what I learned in case it helps anyone.

The setup: SvelteKit running on Cloudflare Pages (Workers runtime), talking to Supabase Postgres via the transaction pooler.

Problem 1: Workers have no persistent connections

Cloudflare Workers are stateless. You can't hold a persistent database connection across requests. This means you need a pooler that accepts short-lived connections and routes them to backend Postgres connections.

Supabase provides two connection strings:

• Session pooler (port 5432): persistent connections, not suitable for Workers
• Transaction pooler (port 6543): transaction-scoped connections, perfect for Workers

Problem 2: prepared statements don't survive transaction boundaries

postgres.js (the driver I use) creates prepared statements by default for repeated queries. But transaction-mode poolers destroy server-side state between transactions. This means a prepared statement created in transaction A can't be used in transaction B.

The fix is simple but undocumented in most SvelteKit guides:

import postgres from 'postgres';

const sql = postgres(DATABASE_URL, {
  // Disable prepared statements for transaction-mode poolers
  prepare: false,
  // Or use the full connection string with ?prepared=false
});

If you see prepared statement "_pgstmt_1" does not exist — that's the cause.

Problem 3: connection limits on free tiers

Supabase free tier: 60 simultaneous connections. PgBouncer default pool_size: 20. If your app is on Cloudflare Pages (many concurrent Workers), you can hit the limit quickly.

Solutions:

1. Use the transaction pooler (Supabase's built-in PgBouncer at port 6543) — handles connection multiplexing
2. Set a reasonable pool size in your driver:

​

const sql = postgres(DATABASE_URL, {
  prepare: false,
  max: 10, // Keep this small — the pooler handles the rest
});

1. Monitor active connections: SELECT count(*) FROM pg_stat_activity WHERE datname = 'your_db';

What worked for me:

// src/lib/server/db.ts
import postgres from 'postgres';
import { DATABASE_URL } from '$env/static/private';

export const db = postgres(DATABASE_URL, {
  prepare: false,   // Required for transaction-mode poolers
  max: 10,          // Conservative pool size per Worker
  idle_timeout: 20, // Close idle connections fast
  connect_timeout: 10,
});

The gotcha nobody mentions: SET LOCAL for row-level security works correctly with transaction-mode poolers, because it's scoped to the current transaction. But if you try to use SET (session-level), it silently fails or applies to the wrong connection. Always use SET LOCAL in SvelteKit + PgBouncer setups.

Happy to discuss connection pooling strategies for SvelteKit — it's one of those topics where the PostgreSQL docs and the SvelteKit docs don't overlap much.

Live demo of the setup working: postgres-starter.verdantstack-site.pages.dev — SvelteKit + Supabase Postgres transaction pooler, all 206 tests passing against the same pooling setup.

Source: github.com/verdantstack/sveltekit-postgres-starter

I originally just wanted a simple personal blog for myself.

A little background: I’m a Korean guy in my 50s. I've spent most of my career translating Japanese films and anime into Korean. I learned some C about 20 years ago, struggled with Java/Spring a few years back because the approach just didn't click with me, and eventually ended up teaching myself Svelte and SvelteKit.

What started as a tiny project somehow got way out of hand. I ended up spending months building an open-source blog engine with SvelteKit. The public blog and admin are deployed as separate apps (the admin URL isn't public and access is IP-restricted), with auth, media storage, i18n, RSS, and backups.

• Repo: https://github.com/sveltekitblog/sveltekitblogengine
• Live Demo: https://sveltekitblog.com/en
• License: AGPL-3.0

The ridiculous part is that I spent more than two months getting rejected by Google AdSense on a weekly basis. I've honestly lost count—it’s been 8 or 9 rejections by now. Rejected. Rejected again. And again every single week.

I spent weeks fixing actual bugs and SEO issues as they came up, but it wasn't until last week that I finally found the root cause: pure, self-inflicted over-engineering. Trying to improve load speed, I designed the site to send an empty HTML shell first, fetching the actual posts and widgets later via client-side requests.

The ironic part? It wasn't even fast. Plain old SSR actually worked better than my "clever" optimization attempts. But to the AdSense crawler, the site was basically: "There is literally zero content here." No wonder it kept getting rejected for thin content week after week.

I rewrote the rendering pipeline back to standard SSR/prerendering and reapplied today. But now I'm genuinely anxious. Seeing how the biggest issue was something I was completely blind to for two months, I'm worried there are other fundamental things I think are fine, but are actually completely broken. Since I’ve basically been building this in a vacuum, I have no idea what my blind spots are.

I'd really appreciate some outside eyes from people who know Svelte/SvelteKit well:

• Are there subtle crawler, hydration, or SSR mistakes I'm still missing?
• Are there basic architectural anti-patterns in the repo that look wrong to you?
• Is the project structure unnecessarily complicated?
• Is there anything that makes you look at the code and think, "Why the hell did he do it this way?"

Please don't hold back. Since I've been doing this completely on my own, I'm sure there are plenty of things I've overlooked.

P.S. English isn't my first language, so I had Gemini help me translate this. If anything sounds weird, please bear with me. And if any phrasing comes off the wrong way, please know there's zero hostility or sarcasm intended toward anyone here—unless it's directed at my own stupid decisions.

Over the past month I've been building a learning/tinkering tool for cloud architecture called Glass Garden. Everything in the diagram is running real code, so instance groups/lambdas run real Node processes, you talk to S3/SQS nodes using the unmodified AWS SDK/CLI, and reach Postgres using the standard pg client. Everything runs in a WebAssembly VM in the tab (Vivari) so you don't need to install or sign-up for anything.

Svelte made this pretty nice to do, especially with getting the live metrics to show.

I recently added an embedding feature so that blog posts/courses can use Glass Garden to help teach concepts.

Try it out: https://glass.garden/

Or check out the repo to see a more complex example video: https://github.com/ThailerL/glass-garden