Hien Linh Nguyen

When I’m building a new app, this is the data stack I typically reach for: - Firestore as the primary store - MongoDB added selectively, usually for analytics or aggregate queries This stack is fast to ship, easy to reason about, and scales surprisingly well with very little ops overhead. Recently, I asked ChatGPT to pressure-test that default and suggest an ideal data stack based on how I like to work. I half expected the answer to be “use MongoDB for everything.” The actual suggestion surprised me: Consider Postgres over Firestore + MongoDB - A single source of truth - More expressive queries - Cheaper cost curves at scale That started a trade-off discussion. Firestore and MongoDB optimize for speed and simplicity. You pay per operation, denormalize aggressively, and shape data around access patterns. Postgres optimizes for consolidation. One source of truth. Expressive queries. Joins and aggregations without pre-shaping data. You pay for capacity, which feels heavier early, but can be more predictable as usage grows. We also talked about where complexity lives. Firestore’s security rules push authorization into the data layer, which I often prefer. Postgres typically keeps authorization in application code — more explicit, but also easier to neglect as logic grows. MongoDB sits in the middle. Its aggregation framework is more expressive than many people give it credit for, but running multiple data stores introduces synchronization and source-of-truth complexity. I then had ChatGPT model costs across common scenarios. The results weren’t shocking: Firestore + MongoDB are often cheaper early, but as complexity grows, it’s reasonable for the curve to bend in Postgres’s favor — sometimes dramatically. Those scenarios tend to correlate with an undisciplined Firestore architecture: lots of atomic documents, no aggregation, and an “observe everything” mindset. With a bit of discipline, both stacks scale well. In many cases, I’d still expect Firestore + MongoDB to be cheaper. I didn’t come away thinking I should abandon my default. It’s not perfect. Juggling sources of truth can be frustrating, and I do miss more expressive queries. But it’s pragmatic. And more importantly, I came away more aware of what I’m implicitly agreeing to when I choose it. Things are changing fast. My preference may be obsolete in six months. That’s a healthy thing to revisit.

4

there's a misconception that singapore lacks creative, risk-taking builders. i just watched 189 people prove that wrong in 7 hours. we wrapped up the Google DeepMind hackathon this weekend -  800 signups, 189 attendees and 76 submissions - an insane 90%+ completion rate! people shipped more in a single afternoon than i've seen at multi-day hackathons. entire companies were built from scratch. here are some standout projects: - 1st place: neuroflix - an agentic video production company. gemini-powered director orchestrating a scriptwriter, editor, set designer and more. 2. 2nd place: contour - converts 2d maps to flyable 3d terrain. if you're planning ski trips to japan, this is the route mapper you didn't know you needed. 3. 3rd place: unmute - translates text to singapore sign language 4. most "bananas" hack: the chicken must arrive by wayang studio - an ai-voice-comedy action game as they are all open-sourced projects, you could check them out here: https://lnkd.in/gSkEuDTY singapore isn't lacking talent. it's one of the most underrated talent pools out there. what's actually missing are platforms and permission structures that let people go wild. that's why we at 65labs are building spaces like these - give people permission to go crazy and they absolutely deliver. special thanks to the other organizers Thorsten Schaeff Manikantan Krishnamurthy Saad Hamid Clément Parazon Ivan Leo 🥃 Agrim Singh Adlin Zainal Kaspar Hidayat

250

11 Comments

I design systems for a health focused bento chain 50+ stores in Japan. Even after training AI on 30+ years of data (weather, holidays, temperature, etc), demand is still hard to predict. But prediction isn’t the only lever. The other lever is 𝗵𝗼𝘄 𝗳𝗹𝗲𝘅𝗶𝗯𝗹𝗲 𝘆𝗼𝘂𝗿 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘀𝘆𝘀𝘁𝗲𝗺 𝗶𝘀. In push pull terms: Some things must be done when the order comes in (salads, sushi cuts, grilling).  Other things can be done anytime (sauces, processed meats, potato salad, vacuum-sealing items). If you design around that difference, something interesting happens: When demand spikes → stop building stock, focus on orders.  When demand slows → rebuild inventory. Same people. Same hours. Just better allocation.  Demand forecasting helps.  𝗦𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝘀𝗶𝗴𝗻 𝗵𝗲𝗹𝗽𝘀 𝗲𝘃𝗲𝗻 𝗺𝗼𝗿𝗲. ↓ pic of our seasonal bentos/side dishes

21

2 Comments

The dirty secret of “serverless LLMs”? A Reddit thread today captured it well. What many platforms call “serverless” is often just container orchestration with warm pools. Models still need to stay resident, weights still sit in VRAM, and teams quietly pay for GPU residency to avoid painful cold starts. LLMs are fundamentally state-heavy systems. Weights, KV cache, tokenizer state, batching queues , the GPU state is the system. Treating them like stateless web functions works fine in demos, but in production it leads to hidden idle cost and 30–40% average GPU utilization. So the real debate isn’t serverless vs pods. It’s stateless abstractions vs state-aware inference systems. That’s exactly why we’ve been building InferX as a runtime that snapshots fully initialized GPU state and restores it deterministically, instead of relying on warm pools. Different architecture. Different cost model. https://inferx.net

31

4 Comments

Stripe just acquired OpenRouter OpenRouter was valued at 1.3 billion dollars in May. Three months later, Stripe is reportedly paying more than 7 billion dollars for it. Here's the deal, as reported across multiple outlets. OpenRouter was founded in 2023 by Alex Atallah, who previously co-founded OpenSea. It serves 8 million users, and had raised over 150 million total, including a 113 million Series B in May backed by Sequoia, Andreessen Horowitz, Menlo Ventures, and Alphabet's CapitalG. Here's the motive, in both companies' own words. Stripe CEO Patrick Collison framed it as building "the economic infrastructure for AI," combining model routing with the token billing tools Stripe already sells. OpenRouter's Atallah said the two companies share a belief that intelligence will be multi-model, and that developers need a neutral layer to manage it all. The case for why this makes sense. Stripe now owns both halves of the AI transaction loop. OpenRouter decides which model handles a request. Stripe already handles billing and settlement on top of it. Folding both into one pipeline, instead of an external partnership, also gives Stripe direct visibility into enterprise AI spending data. The case analysts are raising against it. OpenRouter's entire value proposition has rested on staying neutral between model providers. A CNBC investigation in July found Chinese origin models made up 46% of US enterprise token usage on the platform. Developers on Hacker News raised the same question within hours of the news breaking: does that neutral routing stay neutral once Stripe's own commercial and regulatory interests sit on top of it. Neither company has confirmed final terms, and Bloomberg notes the price could still change before the deal closes. Once OpenRouter’s routing decisions sit inside a company with its own commercial and regulatory interests riding on the outcome, does neutral still mean neutral?

5