ClickHouse

How long did your viewers wait? Ask your own player data _Ask an AI assistant about your video player's QoE in plain language, straight from your own ClickHouse: questions, answers, MCP setup and the SQL behind each answer._ This is the hands-on companion to How long did your viewers wait? Just ask on Medium, which covers the same idea for product owners. *!One question, one answer, from player events in your own database (demo data).**One question, one answer, from player events in your own database (demo data).* A streaming team's first questions about any week are the same. How long did viewers wait for the video to start? How often did it stall? How many gave up, and how many hit an error? The answers usually sit behind someone else's dashboard, with a history that ends where the retention window ends. If your player events land in a database you own, you can simply ask: an AI assistant such as Claude Desktop or Cursor reads it over the Model Context Protocol (MCP) and answers in plain language. Below are our questions, the answers and the setup. It uses Open Analytics, our player analytics service on Open Source Cloud, but works the same on a pipeline you run yourself. Why the database matters more than the chat window Several analytics products let you chat with your data. What matters is what the assistant reads. With Open Analytics, every player event lands as one row in a ClickHouse database that belongs to you, in EPAS, the open Apache-2.0 Eyevinn Player Analytics Specification. So: - You own the raw events. The assistant reads the same rows you can export or query in Grafana. - There is no forced retention window. The table has no expiry, so nothing is deleted after a fixed period and comparing with the same week last year is a question, not a feature request. Each pipeline includes 30 GB of storage; more is available on request. - The price does not grow with your audience. One flat monthly price, with no per-view billing. The whole pipeline is open source, so you can also run it yourself. Six questions, in plain language We typed these questions into Claude Desktop as shown, against demo data: about 150 simulated sessions over one week on web, phones and TV. No real viewers. [...] marks shortened answers. Before you start: tell the assistant what it is looking at. It can list your tables and columns, but it does not know what a player event means. We first asked three questions without an introduction, and two answers were built on guesses. Startup time ran from the session's first event, not from loading. And it said the failed starts could not be linked to a device or title, because it looked for those fields on the wrong events. Then we pasted this, once, at the top of the conversation: > My player analytics are in the ClickHouse database default, one row per player event, in the table epas_default. > Columns: event, sessionId, timestamp (DateTime64, UTC, millisecond precision), deviceType, contentId, payload (JSON). > deviceType and contentId are only set on the session's metadata event. Events follow the EPAS specification: loading, loaded, playing, buffering, buffered, paused, seeking, seeked, heartbeat, error, stopped. Startup time is the time from a session's first loading to its first loaded. Use timestamp differences inside one session only, and compute durations with dateDiff. Use your own table name. The assistant recalculated startup time unasked and corrected itself: "I was wrong earlier that the failed starts couldn't be linked to devices or content: I had looked for deviceType and contentId on the wrong events." 1. "Which tables do I have, and what period do they cover?" > You have one table: default.epas_default, with 5,098 rows. It covers 2026-10-15 16:28:28 to 2026-10-22 12:56:37 UTC, just under 7 days. There are no other user tables, only ClickHouse's built-in system databases. Start here every time. If the dates look wrong, every later answer is too. 2. "What was our video startup time over the last seven days? Give me the median and the 95th percentile per day." > Using your definition (a session's first loading to its first loaded), the median startup time over the last seven days (16-22 Oct, UTC days) was 0.9-1.2 s. The 95th percentile was 1.4-2.6 s, except on 17 Oct when it reached 4.3 s. | Day (UTC) | Sessions | Median | 95th percentile | |---|---|---|---| | Fri 16 Oct | 18 | 1.18 s | 2.61 s | | Sat 17 Oct | 17 | 1.04 s | 4.34 s | | Sun 18 Oct | 21 | 0.87 s | 1.42 s | | Mon 19 Oct | 23 | 1.05 s | 1.80 s | | Tue 20 Oct | 25 | 0.94 s | 1.51 s | | Wed 21 Oct | 18 | 1.16 s | 2.48 s | | Thu 22 Oct | 11 | 0.90 s | 2.62 s | Look at the 95th percentile, not the average. An average of about a second can hide one viewer in twenty waiting four. 3. "Which device types have the slowest startup? Show the 95th percentile per device, slowest first." > Smart TVs have the slowest startup, with a 95th percentile of 4.34 s. TV devices in general are slower than phones and web. | Device type | Sessions | 95th percentile | Median | |---|---|---|---| | smarttv | 7 | 4.34 s | 1.84 s | | appletv | 7 | 2.48 s | 1.52 s | | androidtv | 3 | 2.40 s | 1.21 s | | android | 35 | 2.06 s | 1.21 s | | ios | 28 | 1.47 s | 0.85 s | | web | 53 | 1.46 s | 0.91 s | It linked this to the previous answer on its own: the slow day was one smart TV start. Many "no device" sessions would mean the player is not reporting metadata: an integration fix, not a quality problem. *!Startup time per device type, slowest first (demo data).**Startup time per device type, slowest first (demo data).* 4. "How much rebuffering did viewers see this week? I want the share of sessions with at least one stall, stalls per session, and the rebuffering ratio: stall time divided by stall time plus play time, ignoring pauses, seeks and startup." > This week (19-22 Oct UTC), viewers saw little rebuffering in total, but it was common. About one in three sessions stalled at least once, and only 0.19% of watch time was spent rebuffering. | Metric | Value | |---|---| | Sessions that started playing | 77 | | Sessions with at least one stall | 28 (36.4%) | | Stalls per session (all started sessions) | 0.64 | | Rebuffering ratio | 0.19% (121 s stalled vs 64,548 s playing) | 5. "How many sessions this week never started playing? Split them into viewers who left before the video started and sessions that failed with an error before the first frame." > This week (19-22 Oct UTC), 5 of 82 sessions never started playing: 3 viewers left before the video started, and 2 sessions failed with an error before the first frame. | Outcome | Sessions | Detail | |---|---|---| | Left before the video started | 3 | no error; waited 2.1 s, 4.6 s and 8.0 s before leaving | | Failed with an error before the first frame | 2 | both Android TV, both error 4004 "Manifest request failed" | They look the same in a play count. One viewer gave up waiting; the other hit a problem you can fix. 6. "What are the most common error codes behind those failed starts?" > There is only one error code behind the failed starts: 4004 (NETWORK), "Manifest request failed." [...] | Code | Category | Message | Failed starts this week | All data (15-22 Oct) | |---|---|---|---|---| | 4004 | NETWORK | Manifest request failed | 2 | 3 | Here a conversation beats a fixed report: "those failed starts" builds on the previous answer, and the assistant found the code inside the event payload on its own, then pointed at manifest delivery rather than the player. *!The error code behind every failed start, found in the event payload (demo data).**The error code behind every failed start, found in the event payload (demo data).* Setup You need an Open Analytics pipeline (or your own EPAS pipeline), a player using one of the SDKs, and an MCP client. 1. Install uv from docs.astral.sh. It runs the open-source mcp-clickhouse server on your own machine; nothing to deploy. 2. Copy your credentials. In Open Analytics, open SQL Access and pick your pipeline to see its host, username and password. 3. Add the server to your assistant's MCP configuration (Claude Desktop and Cursor use the same format), with your own values in braces: { "mcpServers": { "clickhouse": { "command": "uv", "args": ["run", "--with", "mcp-clickhouse", "--python", "3.10", "mcp-clickhouse"], "env": { "CLICKHOUSE_HOST": "{host}", "CLICKHOUSE_PORT": "443", "CLICKHOUSE_USER": "{username}", "CLICKHOUSE_PASSWORD": "{password}", "CLICKHOUSE_DATABASE": "default", "CLICKHOUSE_SECURE": "true" } } } } 4. Restart the assistant and ask question 1. If it lists your epas_ tables, you are done. The SQL Access user can write, but the MCP server runs read-only unless you enable writes (our test insert was refused). Keep it that way, and give other tools their own read-only user. The rows the assistant reads go to its AI provider, so treat it like any tool with access to your data. What to watch for - Say which period you mean. "This week" became Monday to Thursday, and "the last seven days" became seven whole UTC days. Our rolling seven-day query gave a higher stall share (41.7% against 36.4%). Neither is wrong, but a weekly report needs one fixed definition. - The assistant writes SQL, and it can get a definition wrong. Ask it to show the query when a number surprises you, and compare it with the appendix below. Answers can also vary between runs, so for a weekly number, save the query and rerun that in Grafana or as a scheduled report. - On small samples, the percentile method decides the number. With 17 sessions on one day, the assistant's 95th percentile was the slowest session (4.34 s); our interpolating query gave 2.34 s. Tell it which function to use. - Not every metric is ready yet. Watch time, seek distance and completion rate need playhead and duration values, which the SDKs do not yet send in the same unit. Until a fix at ingest ships, keep those per platform. Where to go from here - Open Analytics, with SQL Access and the assistant setup: analytics.apps.osaas.io - The event model: EPAS on GitHub - The MCP server: mcp-clickhouse on GitHub - Player SDKs: web (npm install @eyevinn/player-analytics-client-sdk-web), Android, iOS and tvOS Appendix: what the assistant ran These are the tested definitions behind questions 2 to 5, so you can check an answer or save it as a fixed report. Replace epas_default with your table name. They were tested on ClickHouse 24.10 with known-answer data and a real web SDK session. How the assistant's answers compared with these queries. We ran the queries below on the same demo data the same morning. Where the numbers differ, it is because the assistant chose a different period or a different way to compute a percentile, not because it misread the data: - Question 1: same table, 5,098 rows, same first and last timestamp. - Question 2: most days match to within a few hundredths of a second. On days with few sessions, its 95th percentile is the day's slowest session (4.34 s on 17 Oct), while the query below interpolates between the two slowest (2.34 s). - Question 3: same order at the top (smart TV, then Apple TV); small device groups move around with the period. - Question 4: it used Monday to Thursday; the query below uses a rolling seven days, so it reports 41.7% of sessions with a stall, 0.76 stalls per session and a 0.22% ratio. - Questions 5 and 6: same error code, 4004, and the same two failed starts this week. Startup time, median and 95th percentile per day (question 2) SELECT day, count() AS sessions, round(quantile(0.5)(startup_ms)) AS p50_ms, round(quantile(0.95)(startup_ms)) AS p95_ms FROM ( SELECT sessionId, toDate(minIf(timestamp, event = 'loading')) AS day, dateDiff('millisecond', minIf(timestamp, event = 'loading'), minIf(timestamp, event = 'loaded')) AS startup_ms FROM epas_default WHERE timestamp > now() - INTERVAL 7 DAY GROUP BY sessionId HAVING countIf(event = 'loading') > 0 AND countIf(event = 'loaded') > 0 ) GROUP BY day ORDER BY day; Startup time by device type (question 3) SELECT if(device = '', '(no metadata)', device) AS device, count() AS sessions, round(quantile(0.5)(startup_ms)) AS p50_ms, round(quantile(0.95)(startup_ms)) AS p95_ms FROM ( SELECT sessionId, anyIf(deviceType, event = 'metadata' AND deviceType != '') AS device, dateDiff('millisecond', minIf(timestamp, event = 'loading'), minIf(timestamp, event = 'loaded')) AS startup_ms FROM epas_default WHERE timestamp > now() - INTERVAL 7 DAY GROUP BY sessionId HAVING countIf(event = 'loading') > 0 AND countIf(event = 'loaded') > 0 ) GROUP BY device ORDER BY p95_ms DESC; Rebuffering: share of sessions, stalls per session and ratio (question 4) WITH ordered AS ( SELECT sessionId, event, timestamp, multiIf(event IN ('playing', 'buffered'), 'playing', event = 'buffering', 'rebuffering', event IN ('init', 'loading', 'loaded', 'paused', 'seeking', 'seeked', 'stopped', 'error'), 'other', NULL) AS new_state, -- order for events that share a millisecond indexOf(['init', 'metadata', 'loading', 'loaded', 'seeking', 'seeked', 'buffering', 'buffered', 'paused', 'playing', 'heartbeat', 'bitrate_changed', 'warning', 'error', 'stopped'], event) AS seq FROM epas_default WHERE timestamp > now() - INTERVAL 7 DAY ), intervals AS ( SELECT sessionId, event, anyLast(new_state) OVER w_upto AS state, dateDiff('millisecond', timestamp, leadInFrame(timestamp, 1, timestamp) OVER w_next) AS ms FROM ordered WINDOW w_upto AS (PARTITION BY sessionId ORDER BY timestamp, seq ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW), w_next AS (PARTITION BY sessionId ORDER BY timestamp, seq ROWS BETWEEN CURRENT ROW AND 1 FOLLOWING) ), sessions AS ( SELECT sessionId, countIf(event = 'buffering') AS rebuffers, sumIf(ms, state = 'rebuffering') AS rebuffer_ms, sumIf(ms, state = 'playing') AS playing_ms FROM intervals GROUP BY sessionId HAVING playing_ms > 0 ) SELECT count() AS played_sessions, round(100 * countIf(rebuffers > 0) / count(), 1) AS pct_sessions_rebuffered, round(sum(rebuffers) / count(), 2) AS rebuffers_per_session, round(sum(rebuffer_ms) / 1000, 1) AS rebuffer_seconds, round(100 * sum(rebuffer_ms) / (sum(rebuffer_ms) + sum(playing_ms)), 2) AS rebuffer_ratio_pct FROM sessions; Exits before start and start failures (question 5) SELECT count() AS sessions, countIf(played) AS started, countIf(NOT played AND NOT failed) AS exits_before_start, countIf(failed) AS start_failures, round(100 * countIf(NOT played AND NOT failed) / count(), 1) AS ebvs_pct, round(100 * countIf(failed) / count(), 1) AS vsf_pct FROM ( SELECT sessionId, countIf(event = 'playing') > 0 AS played, countIf(event = 'error') > 0 AND (countIf(event = 'playing') = 0 OR minIf(timestamp, event = 'error') < minIf(timestamp, event = 'playing')) AS failed FROM epas_default WHERE timestamp > now() - INTERVAL 7 DAY GROUP BY sessionId HAVING countIf(event = 'loading') > 0 ) A start failure is an error event before the first playing. For question 6, read the code from the payload with JSONExtractString(payload, 'code'). ---

You don't have to take my word for it. The ClickHouse CTO (who opened the original removal PR) updated his post after reviewing our explanation and our fully open-source v0.4-beta submission[0]: > We clarified with the author - while the binary had signs of optimization for specific benchmark queries, we have a reason to believe that the actual runtime didn't use per-query kernels... The usage of a query condition cache and cached statistics per granule is legitimate. The submission of a closed source preview version fine-tuned for benchmark was shady nevertheless. However, the new submission #2751 should move us post all the concerns. Submitting an incomplete, closed-source preview build was a mistake on my part. Since then, we open-sourced a new version with full SQL support, ClickHouse merged it back into ClickBench, and the new version actually runs 7% faster (geomean) than the preview build that was removed. [0] ClickBench#2165

Building a Server-Side Event Tracking Application The percentage of web users browsing with built-in browser tracking protection enabled is rapidly growing, and as browsers begin to ship with these features enable by default, like Apple’s ITP, the client-side attribution techniques that digital advertisers have relied on for years will become progressively less effective. I do some work with a software company who’s primary audience is younger tech-savvy users. Based on what we’ve tracked over the past 6 months, over 30% of their audience has tracking protection enabled, and an even larger percentage are on mobile devices. In a scenario like this, server-side tracking is the only accurate and effective approach to connect paid ad hits to web conversions attribution, but the options available aren’t so great. Server-side Event Tracking Software - Segment can do this well, but it’s usually very expensive for companies with a decent amount of volume and there are certain circumstances where you’ll end up coding your own cloud functions to get what you need - Google Tag Manager server-side tagging provides a close to free alternative, but it’s difficult to set up, has a lot of limitations and I have a feeling it will be detected and blocked by tracking protection in the near future - mParticle is a good alternative to Segment, but it has the same drawbacks - ClickHouse is a great option for high volume data, but it only handles the collection of events. Options for Server-side Event Tracking After reviewing the lackluster options, we decided to build our own system using the Laravel web application framework. This has many distinct advantages: - No limitations to what we can do: we can support every advertiser that can receive server side events - Stay under the radar with a less detectable tracking patterns - Ability to rapidly adapt with the changing landscape Custom Server-side Event Tracking Web Application !Custom server-side event tracking API built with Laravel While we did build our own web application to do this, we didn’t do it from scratch. Laravel provides many built-in capabilities that were ideal for us to work with, including an API ORM and API routing. From a business perspective, the web application is handling the following for us: 1. Marketing websites track pageviews and events by making an API request to a subdomain 2. When the API’s receive an event or pageview it makes outgoing API requests to advertising platforms like TikTok, Facebook and Google Ads To meet the strict rules of various tracking protection mechanisms, we’re using a server-side 1st-party cookie to track the user session. This cookie stores the click ID and other details about the first visit, and creates an anonymous identifier that persists in that user’s browser. Cross-device Attribution Tracking On the marketing website, a web based application process collects and verifies their phone number. The phone number is verified using an OTP text message, where they’re provided with a unique code they have to enter to confirm it is in fact their phone. Once that phone number is verified, a unique user_id is provided to that user, and we can associate that device with the individual anonymously. > This approach allows us to handle cross device attribution seamlessly If that person starts the application process on their laptop but doesn’t finish, they can continue later on their phone by re-verifying their phone again. This allows us to accurately identify the same person from their laptop and their phone. Technical Details To handle all this fancy stuff for a reasonably large volume of users, we’ve used the following technical approach. Under the hood it’s not all that complex, though we do go beyond what’s mentioned here to provide additional models for reporting and audience generation. These are the exact types of things that are difficult to do with off the shelf systems. This system is effectively a micro, DIY OLAP (online analytical processing) application. We use it to collect and store data from multiple data sources, including websites, applications and internal systems. Incoming API Requests from Marketing Website(s) !Event model table in MySQL database table How it works 1. API routes receive incoming POST requests with JSON payloads. 2. Payloads are validated with custom rules and return appropriate HTTP responses. 3. Valid incoming requests create a new Event model, storing the request, response, event name and user details into a MySQL database table with JSON type columns. Outgoing API Requests to Advertising Platforms !Track model table in MySQL database table How it works 1. A job is pushed into a Redis powered queued for background processing by the server. This job contains methods for each advertising platform that we’ll make an API request to. 2. The server processes jobs from the queue, creating a new Track model record for each outgoing API request made. Each record contains an incoming_id column that creates a many-to-one relationship with the incoming event that triggered it. Cloud Hosting  We’re hosting the application with Vapor using AWS resources under the hood. This allows us to comply with strict security protocols by keeping the application in a private cloud. The URL used is a subdomain of the main corporate website where paid advertising is driven to, allowing us to use a 1st-party cookie on both the API server and the marketing website receiving paid ad hits. Benefits The things that make this worth the effort. Performance !Fast changing analytical landscape, like a speeding car This custom application is actively running as we speak, and based on what we’ve seen so far, it’s an absolute beast. It has met all of our needs for tracking server-side conversion events and pageviews reliably, and has also been configured to handle custom audience generation and reporting too. The redis queue handles spikes in volume really well, processing items one by one no matter how many are received. The cloud host has been configured with auto-scaling, and it will scale up automatically to handle traffic bursts, and scale down when volumes are low. Smart Errors & Replays We’ve configured CloudWatch logging to notify us when exceptions or errors do occur, which allows us to react quickly to solve them. > Errors are bound to happen, especially in a system that connects to outside services which can change without notice. Most of these errors will occur with the outgoing API requests, as those are the aspects that will change most frequently without us knowing (thanks Facebook). By using the queue we’re able to record these errors and all associated data that was sent in to the job that triggered it. When we do fix the issue we can replay those events that previously failed. Most if not all server-side side event tracking API’s typically receive an event datetime that represents when it occurred. We use this pattern to our advantage, and when the events are replayed the datetime of the error is used to retroactively backfill the requests. The ability to replay outgoing requests that previously error’d out provides us with a way to track every single valid event we’ve received, no matter what happens. Fast Adaptation to Changing Landscape Limitations and server-side tracking APIs are changing all the time, and this system gives us the ability to quickly change with them. We can move much faster than if we were dependent on a third-party software provider. To keep up with these rapid changes I highly recommend Cookie Status. It’s a great resource for understanding the specific technical limitations imposed by various tracking protection mechanisms implemented by the major browsers and browser engines. Authors Note If you’re looking for a dependable analytics consultant and/or web app developer to build something similar for you, please let me know I’m available for hire. I have a lot of real-world experience building systems like this, which improve the ROI of digital advertising spend by reducing customer acquisition costs.

I commend Orkes for funding a Jepsen report knowing that it could be published this harshly. I question the wisdom of doing so, but it at least speaks to the team's integrity. Building databases is very hard; I know this from personal experience. Disclosure: I'm a software engineer on the core team at a different database company, but we focus on time-series use cases and do not compete in the ACID/OLTP space ParticleDB is targeting. I decided to dig into these claims a bit. > Its also faster than Redis for KV ParticleDB's own benchmarks[0] come with several caveats. Much of the win over Redis seems to come from comparing ParticleDB on 48 cores to Redis's single execution thread, from what I can tell. - On a single client in async mode, ParticleDB loses on writes at 0.86-0.90x and ties on GET. - SET at 512 clients reaches 4.81x Redis, but that's about 18.7k ops/s per allocated core vs Redis's 186k on one thread. For comparison, GET at 512 clients works out to about 33.8k ops/s per allocated core vs Redis's 228k. - Tail latency on SET is much worse, e.g. p99 of 49ms vs 5.3ms for async SET at 512 clients and 306ms vs 41ms for durable mode with pipelining. - Each test was 8 seconds long on 100k keys, but the Jepsen report saw throughput decline linearly over an hour, even on small datasets. > also numbers show this should be top on clickbench Would this claim survive after validating query results? Regardless, it's moot, because it doesn't survive on its face either. On hot runs, by my calculations from the numbers in the Clickbench PR[1], ParticleDB scores about 1.5x better than ClickHouse, however Umbra still scores about 1.5x better than ParticleDB. The fact that `GROUP BY URL` (Q33/Q34) beats `GROUP BY UserID` (Q15) by 4x on a `c6a` is also puzzling to me. Only a handful of 100+ ClickBench results that I checked do this, and ParticleDB's ratio is the most extreme. It also speeds up only 2.2x when going from 16 to 192 vCPUs, while Umbra, ClickHouse, and ElosDB manage 7-10x. This makes me wonder whether the ParticleDB submission may inadvertently be using some precomputation/intermediate caching, despite final result caching seemingly having been disabled. [0]: particledb.ai [1]: ClickBench#2952

Turso has been working on something like this for almost 2 years now tursodatabase/turso Last I checked it wasn't going too well, and it does not seem fixed: ClickBench#336 ClickBench#1009 "No matter how hard I try, it does not work :("

Christ on a cream cracker, clickhouse labeled the previous ParticleDB submissions as jokes github.com/ClickHouse/ClickBench/pulls

How we improved bloom filters in parquet-rs [1], now adopted by ClickHouse [2]: pydantic.dev [1]: arrow-rs#9628 [2]: ClickHouse#119230

Seventeen Seconds to Parse One Name: A Security Scan Across Eleven PHP Projects This is a 16 KB name: $row = 'Smith, ' . str_repeat('V ', 8188); (new \Iliaal\NameParser\Parser())->parse($row); On nameparser 1.5.0, the last version before the fix, that call takes 17.4 seconds of CPU on my i9-13950HX. On 1.7.0 it takes 0.064 seconds. Each V is a candidate roman-numeral suffix, and the old suffix scan walked back over every earlier token for each one, so the cost grew with the square of the input. Nothing about it is exotic. It is a plausible shape for a junk row in a CSV import, and it pins a PHP worker for as long as the row keeps coming. I didn't find it. A security scan did, and the same scan ran across all ten of my PHP extensions as well. In the first three weeks of October each project got a full pass: one coordinating session, a set of subagents reading code and writing proof-of-concept exploits, and a separate verifier that re-ran every finding before it counted, on its own ASan and release builds for the C code. Everything below ships in releases from the last few weeks. Two other things landed in the same window. PHP's October security releases changed what memory_limit does, which forced code changes in three extensions and a same-day round of re-releases in five more. And DuckDB 2.0 went GA; pdo_duckdb bundles it as of today. What the scans found, and what is fixed Every project in the table has a release that carries its fixes. The counts are findings confirmed by the verifier, fixed, and released; severities are the verifier's, not the scanner's first guess. | Project | Fixed in | Confirmed and fixed | |---|---|---| | phpser | 0.7.1 | 19: 1 high, 5 medium, 13 low | | mdparser | 0.8.0 | 12: 1 high, 5 medium, 5 low, 1 informational | | fastchart | 1.8.0 | 15 reproduced, highest medium, including vendored plutovg and plutosvg; two UBSan sites in vendored code only partly addressed | | php_clickhouse | 0.13.0 | 1 high, 1 medium, plus low-severity binding fixes and 7 server-triggered crashes in clickhouse-cpp | | pdo_duckdb | 0.8.0 | 6: 1 high, 1 medium, 1 low-medium, 2 low, 1 informational | | fastjson | 0.10.0 | 4: 1 medium, 3 low, plus 1 documentation correction | | php_excel | 2.9.0 | 5: 3 low, 2 informational | | statgrab | 2.3.0 | 4: 2 medium, 2 low, plus a build bug | | fast_uuid | 0.8.1 | 5: 4 low, 1 by-design behaviour changed anyway | | phonetic | 0.4.4 | 3: 1 medium, 2 low | | nameparser | 1.6.0 | 5: 1 medium, 1 low, 3 informational | A few findings in upstream libraries are reported privately to their maintainers and aren't described here until fixes ship. The coordinating model was Mythos 5.1, but most of the work ran on other models: on fastjson, 695 of the 702 assistant messages came from Opus 5.5 subagents doing the reading, fuzzing, and PoC writing. The phpser scan doubled as an A/B/C test of my own tooling against a bare prompt, which I wrote up on X at the time. So the table measures the process more than any one model. fast_uuid and phonetic came back with zero memory-safety bugs, and php_excel's wrapper with nothing above low severity. Bugs that needed no attacker The worst php_clickhouse finding in practice wasn't the high-severity one. It was B-4, which corrupted data on ordinary queries. Decimal and DateTime64 decoding cached each column's scale in a memo keyed on the raw address of the column's type object. clickhouse-cpp allocates a fresh type object per column per block and frees the block after each callback, so the next block's first column could land at the same address and inherit the previous column's scale. Select a scale-2 column next to a scale-6 one with max_block_size=100, and a stored 12.34 came back as 0.001234, with no error. With default settings the verifier still saw 1 wrong cell in 70,000 rows. The test suite never caught it because ASan builds hide it: the sanitizer's quarantine stops freed memory from being reused, so the address never repeats. It took a release build and a real server. 0.13.0 keys the memo correctly. 0.13.0 also fixes a behaviour you should check for before upgrading. A whole-number insert into a Decimal column, 7 into Decimal(9,2), now stores 7.00 as the server does; 0.12 stored 0.07. Code that compensated by passing pre-scaled integers (700 meaning 7.00) will now store 700.00 without complaint. fast_uuid's main finding has the same character. uuid1() and uuid6() with a fixed node and clock sequence kept no last-tick state, so uuid1(1, 7) called 500,000 times produced 61,723 duplicates. The default arguments were fine. 0.8.1 fixes it. Bugs a server, a file, or a document could trigger php_clickhouse's high-severity finding was a heap overflow write. With compression enabled, a malicious or compromised server could send a compressed frame whose declared size was smaller than the 9-byte frame header, and the client wrote past its buffer with bytes the server chose. clickhouse-cpp had already fixed it on master in PR #566, but no clickhouse-cpp release contains the fix yet, and php_clickhouse's prebuilt binaries ship the library. 0.13.0 carries the patch. The same release rejects seven more server-triggered crash shapes, from FixedString(0) columns to Array offsets that run backwards, and stops a packet of a few dozen bytes from committing gigabytes of memory outside memory_limit. I sent the fixes upstream as 15 pull requests; three have merged so far and twelve are open. fastchart's two medium findings were both resource bombs. A 44 KB SVG passed to svgTo*() reached 2,121,264 KiB of resident memory through data URIs and <use> references that slipped past the input gate, all of it outside memory_limit; a 30,000-deep <use> chain crashed the process. A 1 MB CgBI PNG with decoy dimensions decoded into a 16000 by 16000 buffer. 1.8.0 runs the gate on the parsed tree, bounds <use> depth and expansion, and caps decoded images at 4,096 pixels a side. Some heavy but legitimate SVG that used to render slowly now throws a ValueError instead, so test your largest inputs. mdparser's high-severity finding was quadratic parsing: blank lines inside deeply nested lists took 1.7 seconds at 200 KB and 55 seconds at 1 MB. Seven of mdparser's thirteen findings had their root cause in md4c rather than in my code, and the fixes went upstream; md4c merged five of my pull requests for them on October 13. One remaining low-severity signed overflow is still waiting in md4c#374. 0.8.0 also changes generated heading IDs to start with user-content-, which closes a DOM-clobbering finding and breaks existing links to heading fragments when headingAnchors is on. The other high and medium findings pdo_duckdb's high finding was a use-after-free: an appender left open inside a reference cycle could outlive its PDO handle when gc_collect_cycles() or request shutdown freed the handle first. Two of the medium-range findings were the same shape. A memory_limit bailout at the wrong moment during column setup left uninitialised type pointers that were destroyed later; the PoC got the sanitizer to report a destructor running on 0x4141414141414141. 0.8.0 fixes all six. phpser's high finding was that a nested SPL unserialize() ignored allowed_classes. Its legacy handler path ran outside the decoder's context, so a class allowlist set on the outer call never reached the inner one. 0.7.1 fixes it along with eighteen others, most of them bounds on work an untrusted payload could demand. nameparser's quadratic case, from the top of this post, is fixed in 1.6.0. Its release notes say plainly that earlier notes describing hostile-input parsing as linear "did not hold for these shapes". phonetic's medium finding was a 14-byte input, bmpm("de akeaxhaeasz"), that caused an uncatchable fatal error. 0.4.4 turns budget overruns into a catchable ValueError and caps BMPM output at 256 times the input size, after a 1,560-byte input had produced 3.9 MB. memory_limit stopped stopping things PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 shipped on October 21 with the fix for CVE-2026-109618, rated critical. Part of that fix changes what happens when an allocation crosses memory_limit. The engine used to bail out on the spot with a longjmp. Now it records the error, lets the allocation succeed, and raises the fatal at the next safe point in the VM. For PHP code that's invisible. For an extension it isn't. A C loop that decodes a payload or builds rows never reaches a VM safe point, so it keeps allocating past memory_limit until it hits a hard limit, by default twice memory_limit below 1 GiB. At the hard limit the engine calls _exit(): no shutdown functions, no destructors, no session write, and php-fpm loses the worker instead of failing one request. So every loop whose length comes from input has to notice the pending error and stop on its own. This is how phpser does it: /* PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 queue a memory_limit error instead of * bailing out; the allocation still succeeds until a hard limit (2x the soft * limit below 1G) that _exit()s the process. Loops that keep allocating must * stop on their own once the error is pending. */ #ifdef ZEND_HAS_OOM # define PHPSER_HAS_OOM() ZEND_HAS_OOM() #else # define PHPSER_HAS_OOM() 0 #endif A loop check cannot help when a single allocation is sized from a count the payload declares. Those go through the new fallible allocators instead (zend_hash_real_finit(..., true), safe_femalloc, fecalloc), which queue the error and return NULL rather than running into the hard limit. phpser 0.10.0 uses both. mdparser 0.8.1 and pdo_duckdb 0.9.0 do the same for their input-sized loops and presizes. The re-release day There is a catch. The October headers route smart_str growth through a new engine function, smart_str_ferealloc(), from inline header code. An extension compiled against 8.4.27 headers imports that symbol even if it never mentions it, and 8.4.26 doesn't export it. My release workflows built prebuilt binaries against the newest patch of each PHP minor, which had always been the safe choice. On October 26 that meant mdparser 0.8.1, phpser 0.10.0, fastjson 0.10.1, php_clickhouse 0.13.1, and phonetic 0.4.5 all shipped Linux and macOS binaries that died with undefined symbol: smart_str_ferealloc on every PHP 8.4 before 8.4.27 and every 8.5 before 8.5.12. Source builds were fine, because they compile against the PHP they load into. All five were re-released the same day as mdparser 0.8.2, phpser 0.10.1, fastjson 0.10.2, php_clickhouse 0.13.2, and phonetic 0.4.6, and fastchart 1.8.1 picked up the same change before it could break. Their prebuilts now compile against the oldest patch of each minor (8.4.1, since 8.4.0 was never released, and 8.5.0), and each binary has to load on both the oldest and the newest patch before anything uploads. That fix has a cost, and the phpser changelog states it: a binary built against 8.4.1 headers doesn't have the memory_limit stop. To get it, you build from source on a patched PHP. Refusing vulnerable PHP releases The longer-term answer is the opposite trade. pdo_duckdb 0.9.0 makes it today: its prebuilt binaries are built against the patched headers and require PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12 or newer. Load one on 8.4.26 and the process stops at the first call: php: symbol lookup error: /ext/pdo_duckdb.so: undefined symbol: smart_str_ferealloc That message is honest but unfriendly, and it arrives at runtime rather than at startup. The next releases of pdo_duckdb, phpser, and mdparser fix that with a startup check. On PHP 8.3 and newer, the module compares the running patch with the one it was compiled against and refuses to start on an older one, naming both versions. This is mdparser's: if (php_version_id() < PHP_VERSION_ID) { zend_error(E_CORE_WARNING, "mdparser was built for PHP %s and cannot run on PHP %s; " "install a build for this PHP version or build from source", PHP_VERSION, php_version()); return FAILURE; } With that check in place, pdo_duckdb keeps the binaries it already builds against the patched headers, and phpser and mdparser can move theirs back to the patched headers and regain the memory_limit stop. A server still on 8.4.26 gets a clear startup warning instead of a crash on the first request, and with a critical CVE fixed in 8.4.27 it should move anyway. pdo_duckdb 0.9.0: DuckDB 2.0 DuckDB 2.0.0 went GA on October 21, and pdo_duckdb 0.9.0, out today, bundles it in every prebuilt binary. 0.8.0 had already built against the 2.0 previews. Source builds still work against DuckDB 1.5.3 and newer; configure detects 2.0 from duckdb_v2.h, because the 2.0 headers still report C API version 1.5.6, and it refuses to build when 2.0 headers meet an older libduckdb. The upgrade is not transparent, and the README has a full section on it. The one most likely to bite is the file format. DuckDB 2.0 writes new files at storage version 69, and DuckDB 1.5 reads only 64 to 68. If a 1.5 process has to read the file too, ask for the older format when you open it: $db = new PDO('duckdb:/data/shared.duckdb;storage_compatibility_version=v1.5.6'); On the 0.9.0 binary, a file opened that way reports v1.5.0+ in duckdb_databases(), and a default one reports v2.0.0+. Existing 1.5 files keep their format after 2.0 writes to them. The rest is DuckDB's own behaviour: a failed statement now invalidates the whole transaction, integer division by zero throws, single-arrow lambdas are rejected, and the new PEG parser is the default. That last one has a sharp edge for parameter binding: $1_0 means parameter 10 under PEG and parameter 1 under the legacy parser. Each change has a setting that restores 1.5 behaviour. 0.9.0 also adds PDO::DUCKDB_ATTR_NATIVE_STRUCTURES, an opt-in that fetches LIST, ARRAY, STRUCT, TUPLE, MAP, UNION, JSON, and VARIANT values as lossless PHP structures instead of canonical strings, with exact numerics, binary keys, and SQL NULL kept distinct from VARIANT null. VARIANT works top-level and nested, and the appender accepts PHP arrays and objects for it. One fix in 0.9.0 matters even if you never touch 2.0: two PDO connections to the same database file could lose writes and see stale reads. Equivalent paths now share one DuckDB instance while transactions stay connection-local. Performance, with the hardware attached Most of the speed work came before the scans. Apart from the nameparser row, which I re-ran for this post, these are the numbers from each project's changelog with the conditions it states. | Project | Change | Measured on | |---|---|---| | nameparser 1.6.0 | 16 KB hostile row: 17.4 s to 0.064 s | i9-13950HX, PHP 8.4.27 (my rerun of 1.5.0 vs 1.7.0) | | phpser 0.6.0 | range(0, 9999) encodes to 7 bytes; encode 57% faster, decode 66% faster | aarch64 | | phpser 0.7.0 | Signed decode 53 to 85% faster; 1,000-row rowset decodes in 429 KB instead of 645 KB | aarch64 | | fastjson 0.9.0 | fastjson_validate() costs 0.47 to 0.90x a full parse, down from 1.1 to 1.9x | Neoverse-N1 | | fastjson 0.9.0 to 0.10.0 | Key-heavy decode peak memory about 15% lower; file decode peak 9 to 33% lower | Neoverse-N1 | | fast_uuid 0.8.0 | uuid_v4() 76 to 42 ns; uuid_v4_bin_batch(100) 61 to 27 ns per UUID; uuid_v7_bin_batch() 25.9 to 16.6 ns | Neoverse-N1 | | mdparser 0.6.2 | toAst() 5 to 9% faster; retained AST memory 47% lower on softbreak-dense input; code-heavy toXml() output 49% smaller in memory | aarch64, PHP 8.4.25 | | php_clickhouse 0.12.0 | Temporal, string, and IP inserts about 19% faster; IPv4 selects about 12% | 200,000-row probes | The phpser integer-run encoding is the one I'd point at. A run with a constant step is stored as a start, a step, and a count, so range(0, 9999) encodes to 7 bytes and range(0, 999999) to 8. Native serialize() needs 137,790 bytes for the first one. fast_uuid's speedup comes from refilling its random buffer with a userspace AES-256-CTR generator with fast key erasure, instead of a getrandom() call per 8 KiB, on CPUs with AES instructions. It has one caveat, and the changelog states it: clones of one VM snapshot can repeat up to 64 KiB of output per thread. Breaking changes worth reading before you upgrade Most of these releases are drop-in. These are not: - php_clickhouse 0.13.0: whole-number Decimal inserts scale like the server's (above). - mdparser 0.8.0: heading IDs carry a user-content- prefix. - phpser 0.10.0: Closures and other unserializable objects throw instead of quietly encoding NULL. Check what you put in $_SESSION before upgrading. New wire tags since 0.7.0 mean readers must upgrade before writers. - php_excel 2.9.0 and 2.9.1: dates use PHP's timezone rather than the OS one, and text is UTF-8 regardless of the process locale. Apps that relied on the locale to pass non-UTF-8 bytes through will see different output. 2.7.0 also rejects a font from a different ExcelBook in addText(). - fastchart 1.8.0: heavy SVG that used to render slowly may now throw ValueError. - phonetic 0.4.4: oversized BMPM and Daitch-Mokotoff work throws a catchable ValueError rather than ending the request. - statgrab 2.2.2: Statgrab::ERROR_UNSUPPORTED is 44, matching libstatgrab; it was 41. On the feature side, phpser 0.8.0 and 0.9.0 added signed sessions (phpser.session_key, HMAC-SHA256), an APCu serializer (apc.serializer=phpser), keyed payloads, and an exported C API. nameparser 1.4.0 understands joint salutations, so Mr. and Mrs. Brad Smith keeps Brad as the first name, with new isJoint(), getSalutations(), and getPartner(), and 1.4.1 raised first-and-last accuracy on 30,000 NPPES provider rows from 95.94% to 97.18%. statgrab 2.3.1 fixes a heap overflow in the bundled libstatgrab's Linux command-line handling that the scan didn't cover. What a scan is worth None of these projects were neglected before October. Each had a test suite and documentation that said where its limits were. The scans still found an allowlist that didn't reach a nested call, a Decimal that came back ten thousand times too small, and a 16 KB name that took 17 seconds. Two of the most consequential findings sat in code I had already called linear or already tested under ASan, and for the Decimal bug the ASan testing is exactly what hid it. The fixes are released and listed above. Upgrade pdo_duckdb if you are moving to DuckDB 2.0, php_clickhouse if you talk to a server you don't control, and PHP itself to 8.4.27 or 8.5.12 whatever else you do.

Remove pgrust: the entry is cheating (per-query kernels and result caching) View Article | Discussion + AI Summary Summary of HN discussion 🧵👇

ClickHouse: Real-time analytics without waiting ClickHouse® is a real-time analytics database management system ClickHouse is an open‑source column‑oriented DBMS that provides real‑time analytical reporting. It’s ideal for developers needing fast SQL queries on large datasets, with options to install locally or use ClickHouse Cloud. Community resources like release calls and meetups keep you in the loop. - Install on Linux, macOS, FreeBSD or use ClickHouse Cloud - Official website, docs, tutorials, and YouTube channel for learning - Regular release calls and global meetups for community support Repo: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51k stars | C++ | Apache-2.0 Follow for a new open source repo every day. #opensource #cpp #sql #database #analytics #Shorts [ar] ClickHouse: تحليلات فورية دون انتظار ClickHouse® هو نظام إدارة قواعد بيانات لتحليلات البيانات في الوقت الفعلي. ClickHouse هو نظام إدارة قواعد بيانات مفتوح المصدر، يعتمد على الأعمدة، ويوفر تقارير تحليلية فورية. يُعدّ مثاليًا للمطورين الذين يحتاجون إلى استعلامات SQL سريعة على مجموعات بيانات ضخمة، مع خيارات للتثبيت محليًا أو استخدام ClickHouse Cloud. تُبقيك موارد المجتمع، مثل اجتماعات الإصدارات واللقاءات، على اطلاع دائم. - التثبيت على Linux أو macOS أو FreeBSD أو استخدام ClickHouse Cloud - الموقع الرسمي، والوثائق، والدروس التعليمية، وقناة YouTube للتعلم - اجتماعات إصدارات دورية ولقاءات عالمية لدعم المجتمع المستودع: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51 ألف نجمة | C++ | Apache-2.0 تابعنا للحصول على مستودع جديد مفتوح المصدر يوميًا. #opensource #cpp #sql #database #analytics #Shorts [bn] ClickHouse: কোনো অপেক্ষা ছাড়াই রিয়েল-টাইম অ্যানালিটিক্স ক্লিকহাউস® একটি রিয়েল-টাইম অ্যানালিটিক্স ডাটাবেস ম্যানেজমেন্ট সিস্টেম। ক্লিকহাউস একটি ওপেন-সোর্স কলাম-ভিত্তিক ডিবিএমএস যা রিয়েল-টাইম অ্যানালিটিক্যাল রিপোর্টিং প্রদান করে। এটি সেইসব ডেভেলপারদের জন্য আদর্শ যাদের বড় ডেটাসেটের উপর দ্রুত SQL কোয়েরি প্রয়োজন, এবং এটি স্থানীয়ভাবে ইনস্টল করা বা ক্লিকহাউস ক্লাউড ব্যবহার করার বিকল্প রয়েছে। রিলিজ কল এবং মিটআপের মতো কমিউনিটি রিসোর্স আপনাকে সবকিছুর সাথে আপ-টু-ডেট রাখে। - লিনাক্স, ম্যাকওএস, ফ্রিবিএসডি-তে ইনস্টল করুন অথবা ক্লিকহাউস ক্লাউড ব্যবহার করুন - শেখার জন্য অফিসিয়াল ওয়েবসাইট, ডক্স, টিউটোরিয়াল এবং ইউটিউব চ্যানেল - কমিউনিটি সাপোর্টের জন্য নিয়মিত রিলিজ কল এবং গ্লোবাল মিটআপ রেপো: ClickHouse/ClickHouse ClickHouse/ClickHouse | ৫১ হাজার স্টার | C++ | Apache-2.0 প্রতিদিন একটি নতুন ওপেন সোর্স রেপোর জন্য ফলো করুন। #opensource #cpp #sql #database #analytics #Shorts [de-DE] ClickHouse: Echtzeit-Analysen ohne Wartezeit ClickHouse® ist ein Datenbankmanagementsystem für Echtzeitanalysen. ClickHouse ist ein Open-Source-Datenbankmanagementsystem mit spaltenorientierter Datenbank, das Echtzeit-Analyseberichte erstellt. Es ist ideal für Entwickler, die schnelle SQL-Abfragen auf großen Datensätzen benötigen. Die Installation ist lokal möglich, alternativ kann ClickHouse Cloud genutzt werden. Community-Ressourcen wie Release-Meetings und Treffen halten Sie auf dem Laufenden. - Installation unter Linux, macOS, FreeBSD oder Nutzung der ClickHouse Cloud - Offizielle Website, Dokumentation, Tutorials und YouTube-Kanal zum Lernen - Regelmäßige Release-Meetings und globale Treffen für Community-Support Repository: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51.000 Sterne | C++ | Apache-2.0 Folgen Sie uns für täglich neue Open-Source-Repositorys. #opensource #cpp #sql #database #analytics #Shorts [es-US] ClickHouse: Análisis en tiempo real sin esperas ClickHouse® es un sistema de gestión de bases de datos para análisis en tiempo real. ClickHouse es un sistema de gestión de bases de datos (DBMS) de código abierto orientado a columnas que proporciona informes analíticos en tiempo real. Es ideal para desarrolladores que necesitan consultas SQL rápidas en grandes conjuntos de datos, con opciones para instalarlo localmente o usar ClickHouse Cloud. Los recursos de la comunidad, como las reuniones de lanzamiento y los encuentros, te mantienen al día. - Instalación en Linux, macOS, FreeBSD o uso de ClickHouse Cloud. - Sitio web oficial, documentación, tutoriales y canal de YouTube para aprender. - Reuniones de lanzamiento periódicas y encuentros globales para brindar soporte a la comunidad. Repositorio: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51.000 estrellas | C++ | Apache 2.0 Síguenos para descubrir un nuevo repositorio de código abierto cada día. #códigoabierto #cpp #sql #basesdedatos #análisis #Shorts [fr-FR] ClickHouse : L'analytique en temps réel sans attendre ClickHouse® est un système de gestion de bases de données analytiques en temps réel. ClickHouse est un SGBD open source orienté colonnes qui fournit des rapports analytiques en temps réel. Il est idéal pour les développeurs ayant besoin de requêtes SQL rapides sur de grands ensembles de données, avec la possibilité de l'installer localement ou d'utiliser ClickHouse Cloud. Des ressources communautaires, telles que des réunions de mise à jour et des rencontres, vous permettent de rester informé. - Installation sur Linux, macOS, FreeBSD ou utilisation de ClickHouse Cloud - Site web officiel, documentation, tutoriels et chaîne YouTube pour apprendre - Réunions de mise à jour régulières et rencontres internationales pour le soutien de la communauté Dépôt : ClickHouse/ClickHouse ClickHouse/ClickHouse | 51 000 étoiles | C++ | Apache-2.0 Suivez-nous pour découvrir un nouveau dépôt open source chaque jour. #opensource #cpp #sql #database #analytics #Shorts [hi] ClickHouse: बिना किसी इंतज़ार के रियल-टाइम एनालिटिक्स क्लिकहाउस® एक रीयल-टाइम एनालिटिक्स डेटाबेस मैनेजमेंट सिस्टम है। क्लिकहाउस एक ओपन-सोर्स कॉलम-ओरिएंटेड डीबीएमएस है जो रीयल-टाइम एनालिटिकल रिपोर्टिंग प्रदान करता है। यह उन डेवलपर्स के लिए आदर्श है जिन्हें बड़े डेटासेट पर तेज़ SQL क्वेरी की आवश्यकता होती है, और इसे स्थानीय रूप से इंस्टॉल करने या क्लिकहाउस क्लाउड का उपयोग करने के विकल्प उपलब्ध हैं। रिलीज़ कॉल और मीटअप जैसे सामुदायिक संसाधन आपको नवीनतम जानकारी से अवगत रखते हैं। - इसे Linux, macOS, FreeBSD पर इंस्टॉल करें या क्लिकहाउस क्लाउड का उपयोग करें। - सीखने के लिए आधिकारिक वेबसाइट, दस्तावेज़, ट्यूटोरियल और YouTube चैनल उपलब्ध हैं। - सामुदायिक सहायता के लिए नियमित रिलीज़ कॉल और वैश्विक मीटअप आयोजित किए जाते हैं। रेपो: ClickHouse/ClickHouse क्लिकहाउस/क्लिकहाउस | 51k स्टार | C++ | अपाचे-2.0 हर दिन एक नए ओपन सोर्स रेपो के लिए फॉलो करें। #opensource #cpp #sql #database #analytics #Shorts [id] ClickHouse: Analitik real-time tanpa menunggu ClickHouse® adalah sistem manajemen basis data analitik waktu nyata ClickHouse adalah DBMS berorientasi kolom sumber terbuka yang menyediakan pelaporan analitik waktu nyata. Sistem ini ideal untuk pengembang yang membutuhkan kueri SQL cepat pada kumpulan data besar, dengan opsi untuk menginstal secara lokal atau menggunakan ClickHouse Cloud. Sumber daya komunitas seperti pengumuman rilis dan pertemuan komunitas akan selalu memberi Anda informasi terbaru. - Instal di Linux, macOS, FreeBSD, atau gunakan ClickHouse Cloud - Situs web resmi, dokumentasi, tutorial, dan saluran YouTube untuk pembelajaran - Pengumuman rilis reguler dan pertemuan komunitas global untuk dukungan komunitas Repositori: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51 ribu bintang | C++ | Apache-2.0 Ikuti untuk repositori sumber terbuka baru setiap hari. #opensource #cpp #sql #database #analytics #Shorts [it] ClickHouse: Analisi in tempo reale senza attese ClickHouse® è un sistema di gestione di database per l'analisi in tempo reale. ClickHouse è un DBMS open source orientato alle colonne che fornisce report analitici in tempo reale. È ideale per gli sviluppatori che necessitano di query SQL veloci su grandi set di dati, con opzioni di installazione locale o utilizzo di ClickHouse Cloud. Risorse della community come release call e meetup ti tengono aggiornato. - Installazione su Linux, macOS, FreeBSD o utilizzo di ClickHouse Cloud - Sito web ufficiale, documentazione, tutorial e canale YouTube per l'apprendimento - Release call regolari e meetup globali per il supporto della community Repository: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51.000 stelle | C++ | Apache-2.0 Seguici per un nuovo repository open source ogni giorno. #opensource #cpp #sql #database #analytics #Shorts [iw] ClickHouse: ניתוח נתונים בזמן אמת ללא המתנה ClickHouse® היא מערכת ניהול מסדי נתונים אנליטית בזמן אמת ClickHouse היא מערכת ניהול מסדי נתונים בקוד פתוח המספקת דיווח אנליטי בזמן אמת. היא אידיאלית עבור מפתחים הזקוקים לשאילתות SQL מהירות על מערכי נתונים גדולים, עם אפשרויות להתקנה מקומית או שימוש ב-ClickHouse Cloud. משאבי קהילה כמו שיחות שחרור ופגישות שומרים אתכם מעודכנים. - התקנה על לינוקס, macOS, FreeBSD או שימוש ב-ClickHouse Cloud - אתר רשמי, מסמכים, מדריכים וערוץ YouTube ללמידה - שיחות שחרור קבועות ומפגשים גלובליים לתמיכה קהילתית מאגר: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51 אלף כוכבים | C++ | Apache-2.0 עקבו אחר מאגר קוד פתוח חדש בכל יום. #opensource #cpp #sql #database #analytics #Shorts [ja] ClickHouse：待ち時間なしのリアルタイム分析 ClickHouse®はリアルタイム分析データベース管理システムです。 ClickHouseは、リアルタイム分析レポートを提供するオープンソースの列指向DBMSです。大規模データセットに対して高速なSQLクエリを必要とする開発者に最適で、ローカルインストールまたはClickHouse Cloudの利用が可能です。リリースコールやミートアップなどのコミュニティリソースを通じて最新情報を入手できます。 - Linux、macOS、FreeBSDにインストール、またはClickHouse Cloudを利用できます - 公式ウェブサイト、ドキュメント、チュートリアル、YouTubeチャンネルで学習できます - 定期的なリリースコールとグローバルミートアップでコミュニティサポートを提供しています リポジトリ: ClickHouse/ClickHouse ClickHouse/ClickHouse | スター数51,000 | C++ | Apache-2.0 毎日新しいオープンソースリポジトリが公開されますので、フォローしてください。 #opensource #cpp #sql #database #analytics #Shorts [ko] ClickHouse: 기다림 없는 실시간 분석 ClickHouse®는 실시간 분석 데이터베이스 관리 시스템입니다. ClickHouse는 실시간 분석 보고 기능을 제공하는 오픈 소스 컬럼 지향형 DBMS입니다. 대규모 데이터 세트에 대한 빠른 SQL 쿼리가 필요한 개발자에게 이상적이며, 로컬에 설치하거나 ClickHouse 클라우드를 사용할 수 있습니다. 릴리스 콜 및 밋업과 같은 커뮤니티 리소스를 통해 최신 정보를 얻을 수 있습니다. - Linux, macOS, FreeBSD에 설치하거나 ClickHouse 클라우드를 사용하세요. - 공식 웹사이트, 문서, 튜토리얼 및 YouTube 채널을 통해 학습할 수 있습니다. - 정기적인 릴리스 콜 및 글로벌 밋업을 통해 커뮤니티 지원을 제공합니다. 리포지토리: ClickHouse/ClickHouse ClickHouse/ClickHouse | 별 51,000개 | C++ | Apache-2.0 매일 새로운 오픈 소스 리포지토리를 보려면 팔로우하세요. #오픈소스 #C++ #SQL #데이터베이스 #분석 #Shorts [ml] ClickHouse: കാത്തിരിപ്പില്ലാതെ തത്സമയ അനലിറ്റിക്സ് ClickHouse® ഒരു റിയൽ-ടൈം അനലിറ്റിക്സ് ഡാറ്റാബേസ് മാനേജ്മെന്റ് സിസ്റ്റമാണ് ക്ലിക്ക്ഹൗസ് എന്നത് റിയൽ-ടൈം അനലിറ്റിക്കൽ റിപ്പോർട്ടിംഗ് നൽകുന്ന ഒരു ഓപ്പൺ-സോഴ്‌സ് കോളം-ഓറിയന്റഡ് DBMS ആണ്. വലിയ ഡാറ്റാസെറ്റുകളിൽ വേഗത്തിലുള്ള SQL അന്വേഷണങ്ങൾ ആവശ്യമുള്ള ഡെവലപ്പർമാർക്ക് ഇത് അനുയോജ്യമാണ്, പ്രാദേശികമായി ഇൻസ്റ്റാൾ ചെയ്യാനോ ClickHouse ക്ലൗഡ് ഉപയോഗിക്കാനോ ഉള്ള ഓപ്ഷനുകൾ ഉണ്ട്. റിലീസ് കോളുകൾ, മീറ്റപ്പുകൾ പോലുള്ള കമ്മ്യൂണിറ്റി ഉറവിടങ്ങൾ നിങ്ങളെ ലൂപ്പിൽ നിലനിർത്തുന്നു. - ലിനക്സ്, മാകോസ്, ഫ്രീബിഎസ്ഡി എന്നിവയിൽ ഇൻസ്റ്റാൾ ചെയ്യുക അല്ലെങ്കിൽ ClickHouse ക്ലൗഡ് ഉപയോഗിക്കുക - പഠനത്തിനായി ഔദ്യോഗിക വെബ്‌സൈറ്റ്, ഡോക്‌സ്, ട്യൂട്ടോറിയലുകൾ, YouTube ചാനൽ - കമ്മ്യൂണിറ്റി പിന്തുണയ്ക്കായി പതിവ് റിലീസ് കോളുകളും ആഗോള മീറ്റപ്പുകളും Repo: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51k നക്ഷത്രങ്ങൾ | C++ | Apache-2.0 എല്ലാ ദിവസവും ഒരു പുതിയ ഓപ്പൺ സോഴ്‌സ് റെപ്പോയ്ക്കായി പിന്തുടരുക. #opensource #cpp #sql #database #analytics #Shorts [nl-NL] ClickHouse: Real-time analytics zonder wachten ClickHouse® is een realtime analyse-databasebeheersysteem ClickHouse is een open-source, kolomgeoriënteerd DBMS dat realtime analytische rapportages levert. Het is ideaal voor ontwikkelaars die snelle SQL-query's op grote datasets nodig hebben, met de mogelijkheid om het lokaal te installeren of ClickHouse Cloud te gebruiken. Communitybronnen zoals release-calls en meetups houden je op de hoogte. - Installeren op Linux, macOS, FreeBSD of gebruik ClickHouse Cloud - Officiële website, documentatie, tutorials en YouTube-kanaal om te leren - Regelmatige release-calls en wereldwijde meetups voor communityondersteuning Repository: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51.000 sterren | C++ | Apache-2.0 Volg voor een nieuwe open-source repository elke dag. #opensource #cpp #sql #database #analytics #Shorts [pa] ClickHouse: ਬਿਨਾਂ ਕਿਸੇ ਦੇਰੀ ਦੇ ਰੀਅਲ-ਟਾਈਮ ਐਨਾਲਿਟਿਕਸ ClickHouse® ਇੱਕ ਰੀਅਲ-ਟਾਈਮ ਐਨਾਲਿਟਿਕਸ ਡੇਟਾਬੇਸ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਹੈ ClickHouse ਇੱਕ ਓਪਨ-ਸੋਰਸ ਕਾਲਮ-ਓਰੀਐਂਟਿਡ DBMS ਹੈ ਜੋ ਰੀਅਲ-ਟਾਈਮ ਐਨਾਲਿਟੀਕਲ ਰਿਪੋਰਟਿੰਗ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਡਿਵੈਲਪਰਾਂ ਲਈ ਆਦਰਸ਼ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਵੱਡੇ ਡੇਟਾਸੈੱਟਾਂ 'ਤੇ ਤੇਜ਼ SQL ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਥਾਪਤ ਕਰਨ ਜਾਂ ClickHouse ਕਲਾਉਡ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਵਿਕਲਪਾਂ ਦੇ ਨਾਲ। ਰਿਲੀਜ਼ ਕਾਲਾਂ ਅਤੇ ਮੁਲਾਕਾਤਾਂ ਵਰਗੇ ਕਮਿਊਨਿਟੀ ਸਰੋਤ ਤੁਹਾਨੂੰ ਲੂਪ ਵਿੱਚ ਰੱਖਦੇ ਹਨ। - Linux, macOS, FreeBSD 'ਤੇ ਇੰਸਟਾਲ ਕਰੋ ਜਾਂ ClickHouse ਕਲਾਉਡ ਦੀ ਵਰਤੋਂ ਕਰੋ - ਸਿੱਖਣ ਲਈ ਅਧਿਕਾਰਤ ਵੈੱਬਸਾਈਟ, ਦਸਤਾਵੇਜ਼, ਟਿਊਟੋਰਿਅਲ ਅਤੇ YouTube ਚੈਨਲ - ਕਮਿਊਨਿਟੀ ਸਹਾਇਤਾ ਲਈ ਨਿਯਮਤ ਰਿਲੀਜ਼ ਕਾਲਾਂ ਅਤੇ ਗਲੋਬਲ ਮੁਲਾਕਾਤਾਂ ਰੇਪੋ: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51k ਸਟਾਰ | C++ | Apache-2.0 ਹਰ ਰੋਜ਼ ਇੱਕ ਨਵੇਂ ਓਪਨ ਸੋਰਸ ਰੈਪੋ ਲਈ ਫਾਲੋ ਕਰੋ। #opensource #cpp #sql #database #analytics #Shorts [pl] ClickHouse: Analityka w czasie rzeczywistym bez czekania ClickHouse® to system zarządzania bazą danych do analityki w czasie rzeczywistym. ClickHouse to system DBMS typu open source, zorientowany na kolumny, który zapewnia raportowanie analityczne w czasie rzeczywistym. Jest idealny dla programistów potrzebujących szybkich zapytań SQL do dużych zbiorów danych, z możliwością instalacji lokalnej lub korzystania z chmury ClickHouse. Zasoby społeczności, takie jak spotkania i konferencje dotyczące wydań, pozwalają być na bieżąco. - Zainstaluj na systemach Linux, macOS, FreeBSD lub skorzystaj z chmury ClickHouse - Oficjalna strona internetowa, dokumentacja, samouczki i kanał YouTube do nauki - Regularne spotkania i konferencje dotyczące wydań i globalne spotkania dla wsparcia społeczności Repozytorium: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51 tys. gwiazdek | C++ | Apache-2.0 Obserwuj, aby codziennie otrzymywać nowe repozytorium open source. #opensource #cpp #sql #database #analytics #Shorts [pt-BR] ClickHouse: análise em tempo real sem espera ClickHouse® é um sistema de gerenciamento de banco de dados analítico em tempo real. O ClickHouse é um SGBD orientado a colunas de código aberto que fornece relatórios analíticos em tempo real. É ideal para desenvolvedores que precisam de consultas SQL rápidas em grandes conjuntos de dados, com opções de instalação local ou uso do ClickHouse Cloud. Recursos da comunidade, como chamadas de lançamento e encontros, mantêm você atualizado. - Instale no Linux, macOS, FreeBSD ou use o ClickHouse Cloud - Site oficial, documentação, tutoriais e canal do YouTube para aprendizado - Chamadas de lançamento regulares e encontros globais para suporte da comunidade Repositório: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51 mil estrelas | C++ | Apache-2.0 Siga para receber um novo repositório de código aberto todos os dias. #opensource #cpp #sql #database #analytics #Shorts [ru] ClickHouse: аналитика в реальном времени без ожиданий ClickHouse® — это система управления базами данных для аналитики в реальном времени. ClickHouse — это СУБД с открытым исходным кодом, ориентированная на столбцы, которая обеспечивает аналитическую отчетность в реальном времени. Она идеально подходит для разработчиков, которым нужны быстрые SQL-запросы к большим наборам данных, с возможностью локальной установки или использования ClickHouse Cloud. Ресурсы сообщества, такие как звонки о релизах и встречи, позволяют быть в курсе событий. - Установка на Linux, macOS, FreeBSD или использование ClickHouse Cloud - Официальный сайт, документация, учебные пособия и канал YouTube для обучения - Регулярные звонки о релизах и глобальные встречи для поддержки сообщества Репозиторий: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51 тыс. звезд | C++ | Apache-2.0 Подписывайтесь, чтобы получать новый репозиторий с открытым исходным кодом каждый день. #opensource #cpp #sql #database #analytics #Shorts [ta] ClickHouse: காத்திருக்கத் தேவையில்லாத நிகழ்நேர பகுப்பாய்வு கிளிக்ஹவுஸ்® என்பது ஒரு நிகழ்நேர பகுப்பாய்வு தரவுத்தள மேலாண்மை அமைப்பு ஆகும். கிளிக்ஹவுஸ் என்பது நிகழ்நேர பகுப்பாய்வு அறிக்கைகளை வழங்கும் ஒரு திறந்த மூல நெடுவரிசை சார்ந்த DBMS ஆகும். பெரிய தரவுத்தொகுப்புகளில் வேகமான SQL வினவல்கள் தேவைப்படும் டெவலப்பர்களுக்கு இது மிகவும் ஏற்றது. இதை உள்ளூரில் நிறுவ அல்லது கிளிக்ஹவுஸ் கிளவுடைப் பயன்படுத்த விருப்பங்கள் உள்ளன. வெளியீட்டு அழைப்புகள் மற்றும் சந்திப்புகள் போன்ற சமூக வளங்கள் உங்களை உடனுக்குடன் தெரிந்துகொள்ள உதவுகின்றன. - லினக்ஸ், மேக்ஓஎஸ், ஃப்ரீபிஎஸ்டி ஆகியவற்றில் நிறுவவும் அல்லது கிளிக்ஹவுஸ் கிளவுடைப் பயன்படுத்தவும் - கற்றுக்கொள்வதற்கான அதிகாரப்பூர்வ இணையதளம், ஆவணங்கள், பயிற்சிகள் மற்றும் யூடியூப் சேனல் - சமூக ஆதரவிற்கான வழக்கமான வெளியீட்டு அழைப்புகள் மற்றும் உலகளாவிய சந்திப்புகள் ரெப்போ: ClickHouse/ClickHouse கிளிக்ஹவுஸ்/கிளிக்ஹவுஸ் | 51k நட்சத்திரங்கள் | C++ | அப்பாச்சி-2.0 ஒவ்வொரு நாளும் ஒரு புதிய திறந்த மூல ரெப்போவிற்குப் பின்தொடரவும். #opensource #cpp #sql #database #analytics #Shorts [te] ClickHouse: వేచి చూడాల్సిన అవసరం లేకుండా రియల్-టైమ్ అనలిటిక్స్ క్లిక్‌హౌస్® ​​అనేది ఒక రియల్-టైమ్ అనలిటిక్స్ డేటాబేస్ మేనేజ్‌మెంట్ సిస్టమ్ క్లిక్‌హౌస్ అనేది ఒక ఓపెన్-సోర్స్ కాలమ్-ఓరియంటెడ్ DBMS, ఇది రియల్-టైమ్ అనలిటికల్ రిపోర్టింగ్‌ను అందిస్తుంది. పెద్ద డేటాసెట్‌లపై వేగవంతమైన SQL క్వెరీలు అవసరమయ్యే డెవలపర్‌లకు ఇది చాలా అనువైనది. దీనిని స్థానికంగా ఇన్‌స్టాల్ చేసుకోవడానికి లేదా క్లిక్‌హౌస్ క్లౌడ్‌ను ఉపయోగించుకోవడానికి ఆప్షన్లు ఉన్నాయి. రిలీజ్ కాల్స్ మరియు మీటప్‌ల వంటి కమ్యూనిటీ వనరులు మిమ్మల్ని ఎప్పటికప్పుడు అప్‌డేట్‌గా ఉంచుతాయి. - లైనక్స్, మాక్‌ఓఎస్, ఫ్రీబీఎస్‌డి లలో ఇన్‌స్టాల్ చేసుకోండి లేదా క్లిక్‌హౌస్ క్లౌడ్‌ను ఉపయోగించండి - నేర్చుకోవడానికి అధికారిక వెబ్‌సైట్, డాక్యుమెంటేషన్, ట్యుటోరియల్స్ మరియు యూట్యూబ్ ఛానెల్ - కమ్యూనిటీ మద్దతు కోసం రెగ్యులర్ రిలీజ్ కాల్స్ మరియు గ్లోబల్ మీటప్‌లు రిపో: ClickHouse/ClickHouse క్లిక్‌హౌస్/క్లిక్‌హౌస్ | 51k స్టార్స్ | C++ | అపాచీ-2.0 ప్రతిరోజూ ఒక కొత్త ఓపెన్ సోర్స్ రిపో కోసం ఫాలో అవ్వండి. #ఓపెన్సోర్స్ #cpp #sql #డేటాబేస్ #అనలిటిక్స్ #షార్ట్స్ [uk] ClickHouse: аналітика в реальному часі без очікування ClickHouse® — це система керування базами даних аналітики в режимі реального часу ClickHouse — це СУБД з відкритим вихідним кодом, орієнтована на колонки, яка забезпечує аналітичну звітність у режимі реального часу. Вона ідеально підходить для розробників, яким потрібні швидкі SQL-запити до великих наборів даних, з можливістю локального встановлення або використання ClickHouse Cloud. Ресурси спільноти, такі як релізні дзвінки та зустрічі, допомагають вам бути в курсі подій. - Встановлюйте на Linux, macOS, FreeBSD або використовуйте ClickHouse Cloud - Офіційний веб-сайт, документація, навчальні посібники та канал YouTube для навчання - Регулярні релізні дзвінки та глобальні зустрічі для підтримки спільноти Репозиторій: ClickHouse/ClickHouse ClickHouse/ClickHouse | 51 тис. зірок | C++ | Apache-2.0 Слідкуйте за новим репозиторієм з відкритим вихідним кодом щодня. #відкритийвихіднийкод #cpp #sql #базаданих #аналітика #короткірепортажі