While I’m usually one to also get annoyed at uncurated slop, this doesn’t strike me in any way as LLM text, and likely something the author meant in earnest. I reads lot of LLM text. What part about it appeared generated to you?

From my perspective the piece was well structured, paced and thought through (and yes, a bit long)

The whole paragraph titled "Isn't this just Tidelift again?" is exactly how Claude describes something it is excited about.

I’d recommend looking through the 20+ years of Laurie’s writing in the archives. The LLMs may very well be mimicking him. I wouldn’t put LLM assisted writing past him, but I feel like this is being judged on topical similarity, and is not the standard kind of egregious incoherent slop that has little substance or lacks coherence. See for example:

https://developer.nvidia.com/blog/introducing-cuda-rust-two-...

I saw this for Luna and then looked at the uptime and it said 85%. My interpretation is that this is just a gimmick where they serve the OpenAI flex tier at the same discount OpenAI provides for flex and then fall back to azure

There’s export controls on nvidia. According to Jensen, they expect that Chinese models will start being optimized for Huawei

https://www.dwarkesh.com/p/jensen-huang

They already are.

They're an Evals company. Its right up there in the top nav under Evals > Vending Bench 2

You’re quoting the batch pricing. On demand is 1.5 per input and 9 per M output. This is effectively comparable cost to Gemini 2.5 Pro in a flash tier model

I think the larger part implied is the design will be crappy, because the problem was unexplored

I want to build a shared postgres db with hundreds of small apps (OLTP) accessing shared tables using a RLS model model against well defined tables.

What are other limitations and mitigations folks have used or encountered to support stability and security? Things like

  - Query timeouts to prevent noisy neighbors
  - connection pooling (e.g. pgbouncer) also for noisy neighbors
  - client schema compatibility (e.g. some applications running older versions, have certain assumptions about the schema that may change over time)

If you have people running crappy SQL SELECT, it can be a problem. statement-timeout[0] is your friend here. You still have to be on watch, and teach your users not to write crappy SQL.

You can also limit it by creating read-only replica's and making SELECT's happen on the replica. We don't usually bother, since 99% of our users are employees of ours, we can teach them to not be stupid. Since their usage doesn't change much over time, we can usually just hand them a SQL query and say: here run this instead.

Most of our employees don't even know they have SQL access, it's not like we force people to learn SQL to get their job done. Because of RLS and views, the ones that do SQL don't have to know much SQL, even if they do happen to use it. SELECT * from employees; gets them access to basically all the employee info they could want, but only to the employees they have access to. If you are a manager with 10 people, your select returns only your 10 people.

The payroll staff runs the same query and gets all of the employees they handle payroll for. Since our payroll is done inside of PostgreSQL(thanks plpython[1]), we can do some crazy access control stuff that most systems would never even dream about. Whenever new auditors come in and see that our payroll staff is limited to seeing only the info they need to do payroll, and only for their subset of employees they actually pay, they are awestruck.

The random vendors that can't be taught, we usually hand them a nightly SQLite dump instead. I.e let them pay the CPU cost of their crappy SQL.

Around client schema compatibility. This happens with other models too(API, etc). It's not unique to PG or SQL Databases. You have to plan for it. Since most all of our users interact with views and not with the actual underlying tables, it's not usually that big of a deal. In the extreme cases, where we can't just keep around a view for them, we have to help them along(sometimes kicking and screaming) into a new version.

0: https://www.postgresql.org/docs/current/runtime-config-clien...

1: https://www.postgresql.org/docs/current/plpython.html

github repository here https://github.com/run-llama/liteparse

it's Friday, and I'm avoiding doing work

Ha! Whelp, it is my weekend.

I notice that the python versions and typescript versions are pretty different. Python is sort of class based, with python magic decorators

    class MyWorkflow(Workflow):
        @step
        async def start(self, ctx: Context, ev: StartEvent) -> MyEvent:
            num_runs = await ctx.get("num_runs", default=0)

whereas TS is sort of builder/function based

    import { createWorkflow } from "@llamaindex/workflow-core";
    
    const convertEvent = workflowEvent();
    
    const workflow = createWorkflow();
    
    workflow.handle([startEvent], (start) => {
      return convertEvent.with(Number.parseInt(start.data, 10));

Is there reason for this? });

yea good callout -- python workflows came first, and while we could have directly translated these, the ergonomics around classes in python are not exactly what JS/TS devs expect.

So instead, the goal was to capture the spirit of event-driven workflows, and implement them in a more TS-native way and improve the dev-ux for those developers. This means it might be harder to jump between the two, but I'd argue most people are not doing that anyways.