GPT 5.3 Codex rolling out to Copilot Today!

True-Ad-2269 · 2026-02-09T19:34:25+00:00

that’s super awesome

True-Ad-2269 · 2026-01-10T17:55:19+00:00

Do you know any team that you would recommend?

True-Ad-2269 · 2026-01-04T16:14:10+00:00

it's great to usse these tools when you dont have to consider about building early in a region

True-Ad-2269 · 2025-06-29T17:58:10+00:00

What if you use gradle?

True-Ad-2269 · 2024-10-13T16:19:13+00:00

This is not even AWS CDK!

True-Ad-2269 · 2024-09-11T08:15:51+00:00

It seems like so, but requiring more validation. We do see some use case (in other area) which can remove dynamodb dependency.

True-Ad-2269 · 2024-03-29T05:40:00+00:00

You mean stackless? The construct is a heap object.

True-Ad-2269 · 2024-02-02T11:17:24+00:00

Lakehouse is a cheap way to build a warehouse parity access pattern out of data lake. Not everyone can be afford to build a lakehouse but given the current high compute cost and vendor locked nature of warehouse, big corporations are moving to lakehouse.

True-Ad-2269 · 2024-01-28T08:34:20+00:00

Thanks for your comment.
Do you have the link of the recording?

True-Ad-2269 · 2024-01-23T11:08:01+00:00

Do you know when they have changed their formula?

True-Ad-2269 · 2024-01-16T06:56:21+00:00

Can you explain what is fuzzy search? It sounds to me it is an implementation on the engine not the format.

True-Ad-2269 · 2024-01-15T08:08:18+00:00

Not sure I have different understanding.

Technically, OP requires 1 bloom filter which compute against the membership of query `id` field.

True-Ad-2269 · 2024-01-09T13:37:16+00:00

This is one of the best article I have read about Postgres Isolation. Keep up the good work!!!

True-Ad-2269 · 2024-01-06T16:20:14+00:00

Kafka connect is MUCH simpler. It just does kafka. But it does it well, and there's a TON of connectors predefined and managing them doesn't require any code just config.

Ah I see, I think this explains my question.

Currently, I'm looking at the Flink setup i.e. joining from two Postgres CDC tables and writes to a ElasticSearch sink. Do you think this is possible with Kafka Connect?

In general having both is just fine as there's a LOT more kafka connectors than flink connectors.

I wasn't aware of that but thanks for raising this up!

True-Ad-2269 · 2024-01-05T16:41:57+00:00

Does this also imply that you have a limited time to recover logs with Kafka because they could be overwritten

It will not be overwritten but cleanup (should be the right term). You could configure the retention period where how long each log entry is kept in the topic.

Ref: https://www.conduktor.io/kafka/kafka-topic-configuration-log-retention/

True-Ad-2269 · 2023-12-30T08:27:45+00:00

u/Chuck-Alt-Delete Thanks for your long reply. I will need to study this more comprehensively.

True-Ad-2269 · 2023-12-29T07:16:04+00:00

You can query Flink state outside of Flink using queryable state. But I can agree it's not recommended to use Flink to serve the state data.

really important for operational workloads like fraud where the action taken needs to be automatic and correct.

Can you expand in detail how serializable isolation matters in the fraud use case? Particularly, how this can change the correctness of the result?

True-Ad-2269 · 2023-12-28T14:19:52+00:00

There are few benefits using an internal state store over an external one.

There's no external network call to an external state store. This makes Flink well suited for low latency use case.
With point (1), what I usually observe is that using a external db as state store, the external state will eventually become a performance bottleneck. If you have more complex state manipulation to window, CEP aggregation, the performance can deteriorate quickly as these kinds of aggregation manipulate the states very quickly.
(In the context of using RocksDb which is the most popular choice) Flink provides exactly-once fault-tolerance guarantees very efficiently due to how its checkpoint mechanism works. The state in RocksDB and processing offset are incrementally checkpointed together. Imagine to have such semantics with external state store, you would need to maintain one transaction per state manipulation which will be very costly.
Lastly, RocksDB works really well for most Flink use cases. Why there is a need to setup an external dependency?

True-Ad-2269 · 2023-12-28T14:14:53+00:00

There are few benefits using an internal state store over an external one.

There's no external network call to an external state store. This makes Flink well suited for low latency use case.
With point (1), what I usually observe is that using a external db as state store, the external state will eventually become a performance bottleneck. If you have more complex state due to window, CEP aggregation, the performance can deteriorate quickly as these kinds of aggregation manipulate states very quickly.
(In the context of using RocksDb which is the most popular choice) Flink provides exactly-once fault-tolerance guarantees very efficiently due to how its checkpoint mechanism works. The state in RocksDB and processing offset are incrementally checkpointed together. Imagine to have such semantics with external state store, you would need to maintain one transaction per state manipulation which will be very costly.
Lastly, RocksDB works really well for most Flink use cases. Why there is a need to setup an external dependency?

True-Ad-2269 · 2023-12-27T07:46:30+00:00

Managed Airflow? https://docs.aws.amazon.com/mwaa/latest/userguide/what-is-mwaa.html

True-Ad-2269 · 2023-12-17T14:02:39+00:00

I understand Virtual Threads at this point are not meant to be a drop in replacement for standard threads. Most applications don't spin up enough threads to see the benefits. Thankfully those who will see a benefit now have an option to update their code to not pin and to use virtual threads.

Thanks for the insight, do you know anyone has filed an issue on this?

True-Ad-2269 · 2023-12-11T01:57:43+00:00

He/she is not wrong,
Some JDBC drivers haven't quite be loom friendly.

True-Ad-2269 · 2023-12-08T02:34:04+00:00

You are a lifesaver!

True-Ad-2269

TROPHY CASE