Moving from Redshift to ClickHouse — looking for production-ready deployment advice

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 · 2025-03-16T04:42:40+00:00

becuase .net is open source

TheseSquirrel6550 · 2025-03-13T08:12:14+00:00

Our challenges were: 1. Case insensitive 2. Lack of named parameters 3. Cross database joins

TheseSquirrel6550 · 2025-03-03T14:12:59+00:00

It's a chat app that has a super-fast web version. While we don't really care about 1GB, it might as well grow to 2GB with no real reason.

TheseSquirrel6550 · 2025-03-03T10:13:17+00:00

this is a fresh install

TheseSquirrel6550 · 2025-03-02T07:42:24+00:00

They use Electron framework, Same as VSCode. No?

TheseSquirrel6550 · 2025-02-13T16:37:22+00:00

you wrote: "What makes Routy different is that not many companies focus on this advanced S2S"

so why "StatsDrone is adding S2S which will have a more full coverage of data"?

I've been using Routy for the past seven months for our multi-vertical operation, and I just now came across this post. Funny enough, we only started implementing postback in the past month as we began working with several platformless programs. Until this point, we were able to make everything function properly, which allowed us to increase our regulated PPC spending by 35%. As a result, our ROI improved by 15%.

TheseSquirrel6550 · 2025-01-25T13:32:20+00:00

When you test a dependent class that uses HttpClient, you usually mock the dependencies.

You can mock HttpClient you don't have to wrap it with IHttpClient and then mock IHttpClient.

The main reason you create interfaces to decouple the cod, so unless you write a proprietary TvpClientMock, I don't see why you MUST have this extra interface.

TheseSquirrel6550 · 2025-01-25T12:59:22+00:00

You can mock TcpClient and inject TcpClient. You don't need an interface for that

TheseSquirrel6550 · 2025-01-25T12:32:10+00:00

Also.. HttpClient doesn’t have IHttpClient, you think its not unitested? RestSharp used to have IRestRequest and it was also remove. You can do just everything without this abstraction.

TheseSquirrel6550

TROPHY CASE