Rate limiting when developing with LLMs isn't optional. Redis handles this at scale. But you don't need it yet. Instead, add a rate limit table to Supabase. Track user ID, timestamp, request count. Fixed window is simplest, query on each request, increment if under the limit, block if over. There is one issue with this - concurrent requests. If two requests come in simultaneously for the same user, both can read the count before either increments it, and both pass through. At low traffic this rarely matters, but it's a real tradeoff worth knowing. A fix to this is to increment atomically. Instead of read → check → increment as separate steps, you do it in a single database operation. In Postgres you can use UPDATE ... RETURNING. So when do you actually migrate to Redis? When your atomic Postgres updates become the bottleneck under concurrent load. Or when you're seeing latency on the rate limit check itself. Or when you need distributed rate limiting across multiple servers. Until then, the Supabase table is enough. Build simple. Migrate when the problem is real, not imagined.