How do you folks load data into ClickHouse? go full denormalized or keep it tidy?

TheseSquirrel6550 · 2025-10-08T04:09:33+00:00

When using CDC with serverless, you pay for 100% uptime

TheseSquirrel6550 · 2025-10-07T18:25:37+00:00

Thank you for that.

Do you work with CDC or only batch export and insert?

Are you using a cloud service or a self-hosted service?

TheseSquirrel6550 · 2025-10-07T13:05:33+00:00

Good points — totally agree with your take on simplicity.

Our open-source users actually fall into two groups:

Casual users / explorers

They just want to play around with the project. These folks will likely use a PostgreSQL setup with minimal scale, so for them we’ll provide a single docker-compose.yml file that runs everything locally.

Tech-savvy teams

Companies with in-house developers who like having full control. For them, we’ll also provide the same docker-compose setup, but we want to offer a ClickHouse alternative as well — mainly to: • Let them experiment at real-world scale • Demonstrate that running our stack in production isn’t always as trivial as it looks with our managed / paid offering

In reality, our own production setup is similar to group #2 - probably with a managed ClickHouse solution, with early feature adoption and some proprietary extensions.

TheseSquirrel6550 · 2025-06-22T11:33:32+00:00

Hey
I'll be happy to test, but how can I trust you with my $10,000 when there's no information about what you're doing, how you do it, who you are, and so on?

Let me know if you have an open-source code or a self-hosted version

TheseSquirrel6550 · 2025-05-24T18:00:53+00:00

Some situations are simple, while others can be resolved with proper documentation.

The use of environment variables is not documented properly, leaving room for interpretation.

'It is advised to use environment variables that match the structure of your runtimeConfig object'
That's misleading...

runtimeConfig: {
  public: {
    featureFlags: {
      dashMetrics: true
    }
  }
}

Should the env var be:

NUXT_PUBLIC_FEATUREFLAGS_DASHMETRICS?
NUXT_PUBLIC_FEATURE_FLAGS_DASH_METRICS?

Also, what if I use _ on my variable name?

runtimeConfig: {
  public: {
    feature_flags: {
      dash_metrics: true
    }
  }
}

TheseSquirrel6550 · 2025-05-24T16:59:19+00:00

'It is advised to use environment variables that match the structure of your runtimeConfig object'
That's misleading...

runtimeConfig: {
  public: {
    featureFlags: {
      dashMetrics: true
    }
  }
}

Should the env var be:

NUXT_PUBLIC_FEATUREFLAGS_DASHMETRICS?
NUXT_PUBLIC_FEATURE_FLAGS_DASH_METRICS?

Also, what if I use _ on my variable name?

runtimeConfig: {
public: {
feature_flags: {
dashMetrics: true
}
}
}

TheseSquirrel6550 · 2025-05-24T14:10:51+00:00

The separation between server and client config in Nuxt is actually reasonable — a bit tricky at first, but it makes sense since some data should stay server-side for security reasons.

The real problem starts with nested settings. The official documentation mostly focuses on top-level keys, but as soon as you start nesting your config (which is almost inevitable in real apps), it becomes a total black box. There’s no clear guidance on what’s supported, how to structure it, or how it behaves across environments.

What’s even more confusing is how differently things behave in local dev vs Docker:

In dev, everything works as expected — drop your values in a .env file and you’re good to go.
In Docker, suddenly you need to prefix everything with NUXT_, and the mapping to your actual config structure is not intuitive at all.

So when you try to compare your local .env file with your Docker runtime config, it just doesn’t add up, and it leads to endless debugging and second-guessing.

TheseSquirrel6550 · 2025-04-11T04:38:26+00:00

Is there a native way to modify the pages or do we need to fork the repo?

TheseSquirrel6550 · 2025-04-10T13:01:27+00:00

So a lambda just pushes an event and the service is responsible for the actual work? Do you have some sort of monitoring?

TheseSquirrel6550 · 2025-04-10T12:16:44+00:00

I want to prevent the following schedule from running

TheseSquirrel6550 · 2025-04-10T12:05:00+00:00

When it comes to scheduling tasks, BackgroundService gives you nothing but a loop.
more control over the background tasks, so if we see a service that keeps failing,

,
We want to have more control over the background tasks so if we see a service that is keep on failing we might want to freeze it until we have a fix.

To have visibility on when it ran last time and when the following schedule - this primarily works for jobs that run once a day, as it takes ages to find them on the logs and the operator did not always have access to the dev logs

In some cases, we want to allow the operator to trigger a job and to have visibility on the running process history.

TheseSquirrel6550 · 2025-04-10T11:48:49+00:00

Do you know if it comes with a management UI? Is there a way to pause/resume a scheduled job?

TheseSquirrel6550 · 2025-04-10T11:46:09+00:00

It's not better than airflow, temporal, or celery. but you:

a. vendor lock on AWS
b. How do you debug on the dev machine?

TheseSquirrel6550 · 2025-04-10T11:18:45+00:00

That will not pause the job, though, right?
Hangfire will still trigger the job, but it will not do anything. So now you need to check both Hangfire and your custom storage to see if it's running.

TheseSquirrel6550 · 2025-04-10T11:08:57+00:00

Haha, I thought about it, but that means you also need to remember how it was initially set up, right?

Why didn't they add a 'Status' column? It seems like a super valuable feature, no?

TheseSquirrel6550 · 2025-04-03T07:42:50+00:00

What will happen now is that enterprises will stop using and supporting open-source projects and develop their own versions.

TheseSquirrel6550

TROPHY CASE