标签：#Data

In February, city officials in Cheyenne, Wyoming discovered something in their reclaimed water system that shouldn't have been there: Cupriavidus gilardii , a rare metal-resistant bacterium traced to wastewater discharges from Meta's $800 million data center campus. The contamination shut down Cheyenne's reuse water system for months , and on July 2, the city publicly named Meta's construction entity — a shell company called Goat Systems LLC — as the source. 📖 Read the full version with charts and embedded sources on ComputeLeap → "It's a very, very unpleasant surprise," said City Councilman Pete Laybourn. It shouldn't have been a surprise at all. Cheyenne is just the latest community learning what happens when AI's insatiable demand for compute meets the physical world: contaminated water, noise that residents describe as "living in hell," electricity bills that spike 267%, and — in the most surreal twist — a federal government that deleted its own energy conservation pages while a heatwave slammed the eastern seaboard. The AI industry talks endlessly about parameters, benchmarks, and scaling laws. But the story converging across Reddit, Hacker News, X, and YouTube this week isn't about models. It's about watts, gallons, and the communities living next to the machines. The water problem is worse than you think A Brookings Institution analysis puts the numbers in perspective: a typical data center consumes 300,000 gallons of water every day — equivalent to roughly 1,000 households. Large facilities gulp up to 5 million gallons daily, matching the needs of a town of 50,000. And water demand for data center cooling may rise by 870% as the current build-out continues. The scale is hard to overstate. According to a Consumer Reports investigation , Phoenix-area data centers currently use 385 million gallons annually — a figure projected to explode to 3.7 billion gallons once planned facilities come online. About two-thirds of data centers built since 2022 sit in water-st

A friend messaged me a photo of a sealed booster box last month with one question: "worth it?" He'd already decided, really. The chase card in that set was all over his feed, so the box felt like a good deal. I asked him to send me the pull rates instead of the hype, and we spent twenty minutes turning "worth it?" into something we could actually compute. That exercise is a small, self-contained data problem. It's also a good example of how a clean-looking model can hand you a confident number that doesn't survive contact with reality. If you like building little estimators, this one is worth doing carefully, because the interesting part isn't the formula. It's everything the formula assumes. The formula is the easy part Expected value of a box is a weighted sum. Each card you can pull has a probability and a market value, and you multiply the two across every slot the box gives you. That's it. Undergrad probability. Here's a stripped-down version for a hypothetical set. I'm using made-up numbers so nobody mistakes this for real pull data — the point is the shape of the computation, not the specific set. # One "hit slot" in a box: probabilities cover the full outcome space. # Values are illustrative market estimates in USD. hit_table = [ { " name " : " Alt-art chase " , " p " : 0.0125 , " value " : 180.00 }, { " name " : " Secret rare " , " p " : 0.030 , " value " : 45.00 }, { " name " : " Full-art rare " , " p " : 0.100 , " value " : 8.00 }, { " name " : " Standard hit " , " p " : 0.400 , " value " : 0.55 }, { " name " : " No notable hit " , " p " : 0.4575 , " value " : 0.06 }, ] assert abs ( sum ( row [ " p " ] for row in hit_table ) - 1.0 ) < 1e-9 ev_per_slot = sum ( row [ " p " ] * row [ " value " ] for row in hit_table ) hit_slots_per_box = 36 # e.g. one meaningful slot per pack ev_box = ev_per_slot * hit_slots_per_box print ( f " EV per slot: $ { ev_per_slot : . 2 f } " ) # $4.65 print ( f " EV per box: $ { ev_box : . 2 f } " ) # $167.31 The box costs $150 sea

PostgreSQL provides several planner configuration parameters, such as enable_seqscan and enable_indexscan , that influence how execution plans are generated. These settings affect planning, not the execution of an already-generated plan. With prepared statements, this raises an interesting question. Should planner settings be applied before PREPARE, before EXECUTE, or both? Let's look at a simple example: a "tasks" table with a due date and a "done" status: \ c drop table if exists tasks ; -- a table of tasks with status (done or not) and due date create table tasks ( id bigint generated always as identity primary key , due timestamptz , done boolean ); -- insert 500 tasks, with 1% not done insert into tasks ( due , done ) select now () + interval '1 day' * n , 42 != n % 100 from generate_series ( 1 , 500 ) n ; -- index the todo (partial index) create index on tasks ( due , id ) where done = false ; vacuum analyze tasks ; With a partial index, I indexed only the tasks that are not yet done ( done = false ) because that's my most frequent query pattern: postgres =# explain select id , due , done from tasks where done = false and id > 0 order by due limit 1 ; QUERY PLAN --------------------------------------------------------------------------------------- Limit ( cost = 0 . 13 .. 3 . 60 rows = 1 width = 17 ) -> Index Scan using tasks_due_id_idx1 on tasks ( cost = 0 . 13 .. 17 . 47 rows = 5 width = 17 ) Index Cond : ( id > 0 ) ( 3 rows ) With partial indexes, the condition covered by the index is not even visible in the execution plan because the index itself enforces the condition. Prepared statement I decided to use a prepared statement with all values as parameters. It is probably not a good idea in this case. When a parameter can have only a few different values and you expect different cardinalities for each, you should probably define one query per value, using literals. I'm doing this to illustrate what can happen, with a simple, extreme example: postgres =# pr

AWS recently announced Amazon S3 Annotations, a feature that lets teams attach rich, searchable context such as summaries, classifications, compliance data, or AI-generated insights directly to S3 objects. Annotations can be updated independently of the object and queried across datasets, reducing the need for separate metadata systems. By Renato Losio

Claude models reached GA on Microsoft Foundry with Azure-native billing and governance, but no European data zone exists. Anthropic's own documentation confirms data residency guarantees apply to Bedrock and Vertex AI but not Foundry. European practitioners from banking and healthcare report the offering is unapproved for production. By Steef-Jan Wiggers

The problem with a data breach is not finding evidence. It is connecting it. But let me start where I actually was: 4 AM, last day of the hackathon, staring at this in my terminal. RateLimitError: GroqException - Rate limit reached for model `llama-3.3-70b-versatile` on tokens per day (TPD): Limit 100000, Used 99787, Requested 1616. Please try again in 20m12s. Used 99,787 out of 100,000. My deployment was half done, my demo graph was empty on the server, and the free tier had 213 tokens left. The submission deadline was hours away. I had not slept. I had not eaten. My friends were asleep and I was swapping API keys like a gambler swapping chips. This post is the story of how we got there, and how it ended at 7 in the morning with the best sigh of relief I have ever taken. First, some honesty about how I got here When I joined my first WeMakeDevs hackathon, I did not believe in it. I thought it was one of those ordinary online events. Fake prizes, no follow-through, what would I even get out of it. I joined anyway, mostly out of boredom, got into the Discord, talked to people, made a few connections. I landed in the top 50. A few days later an email showed up: a free Claude Max subscription as a gift. I read it twice. I genuinely could not believe a hackathon had actually delivered something. So when this hackathon opened, I did not hesitate. I messaged my friends and said we are joining as a team this time. Three of us: me (Mehraan), Aqib, and Ubaid. The spark We spent the first evening in our group chat throwing ideas around and shooting most of them down. Then one of my friends dropped a thought that stuck: what happens after a company gets hacked? I started digging into it. The answer is honestly depressing. After a breach, the evidence is everywhere. VPN records. File access logs. The email gateway. Badge readers at the office doors. CCTV. HR notes. Anonymous tips. Each system tells one small piece of the story, and a human analyst has to stitch all of it togeth

Every big social network locks audience data behind auth walls and anti-bot systems. Bluesky went the other way. The AT Protocol is open by design, so public profile data (bios, follower counts, full follower and following lists) is queryable through a documented API without logging in. The whole surface is basically two endpoints: GET https://api.bsky.app/xrpc/app.bsky.actor.getProfile?actor=HANDLE GET https://api.bsky.app/xrpc/app.bsky.graph.getFollowers?actor=HANDLE&limit=100 There's also getProfiles for batching 25 handles per call. Follower lists paginate with a normal cursor , which still works on the graph endpoints. Search is a different story, cursor pagination 403s there now, but that's a topic for another post. For one-off lookups, curl is honestly all you need. Where it gets tedious Bulk. Thousands of profiles, follower exports that run into six figures, weekly snapshots for tracking. Pagination, rate-limit backoff, and stitching the pages together is boring code that has to run reliably. I packaged that part as an Apify actor: Bluesky Profile Scraper . Paste handles or profile URLs, optionally turn on follower/following export, and you get JSON or CSV back with a sourceProfile field linking each follower record to the profile it belongs to. $2 per 1,000 records, runs on a schedule if you want snapshots over time. What people use this for Vetting an influencer's real audience before paying them. Exporting who follows a competitor and what their bios say. Charting follower growth from weekly runs. And enrichment: find who's talking about you with a mentions monitor , then profile those authors to see their actual reach. Bluesky is the only major network right now where any of this is straightforward and stable. Worth using while it lasts.

SQLite Internals, Postgres 19 Checksums, & PL/CBMBASIC Extension Today's Highlights This week, we delve into SQLite's secure deletion and blob updates, explore upcoming data integrity features in PostgreSQL 19, and discover a unique PostgreSQL extension bringing Commodore 64 BASIC to your database. These updates offer insights into database internals, future resilience, and creative extensibility for the SQLite ecosystem. Secure Delete and BLOB Updates in SQLite (SQLite Forum) Source: https://sqlite.org/forum/info/6f3e886a1149c97e0ede9a243281efb05a043705393ea94437ed7c0556315972 This SQLite forum discussion delves into the nuances of secure data deletion and efficient BLOB updates within SQLite databases. Secure deletion is a critical concern for applications handling sensitive data, where simply deleting a row might not zero-out the underlying storage, leaving recoverable remnants. The thread explores methods and implications for ensuring data is truly eradicated when removed, potentially touching on PRAGMA settings or specific file system interactions. Understanding these mechanisms is crucial for developers building secure, embedded applications with SQLite. The conversation also extends to optimizing updates for BLOB (Binary Large Object) data. Efficiently handling large binary data, such as images or documents, in an embedded database like SQLite requires careful consideration to avoid performance bottlenecks and excessive disk I/O. The discussion likely covers strategies for in-place updates, managing free space, and the internal workings of SQLite's storage engine when dealing with variable-length BLOBs. This insight helps developers make informed decisions on schema design and update patterns for improved application performance and data integrity. Comment: This thread offers valuable insights into SQLite's low-level data management, essential for anyone needing to implement robust security or optimize BLOB storage. PostgreSQL 19 to Feature Checksums For All

Introduction I used to think "connecting to a database" was one skill. Turns out it's two: connecting to a database chilling quietly on your own laptop, and connecting to one living in the cloud, behind a login, in this case, an SSL certificate that will not let you in until you treat it with respect. This week I did both. Same tool (Power BI), same dataset, two very different vibes. Grab a coffee, here's the full walkthrough local PostgreSQL first, then Aiven's cloud version, side by side, screenshots and all. Part 1: Local PostgreSQL → Power BI Step 1 : Create a schema Nothing fancy, just giving my table a home: CREATE SCHEMA powerbi ; Step 2 : Import the dataset Right-click the new schema → Import Data in DBeaver, point it at your CSV, and let the wizard do its thing. Step 3 : Check the table landed properly A quick peek at the columns to make sure nothing got mangled on the way in. Step 4 : Connect Power BI In Power BI Desktop: Get Data → Database → PostgreSQL database. In the Server field, type localhost (or 127.0.0.1 ) and your database name. localhost Choose Import , hit OK, and log in with your local username and password. Click Load . That's it. That's the whole local experience. Part 2: Aiven PostgreSQL (Cloud) → Power BI Now for the part that actually taught me something. Step 1 : Grab your connection details Everything you need lives on Aiven's Overview page: Host, Port, Database name, User, SSL mode. Your service URI will look something like this (don't worry, this isn't a real password, Aiven masks it in the console): postgres : // avnadmin : •••••••• @ pg - xxxxxxxx - yourproject . c . aivencloud . com : 22016 / defaultdb ? sslmode = require Step 2 : Import the dataset into Aiven Same DBeaver wizard as before, just pointed at the Aiven connection instead of local. CREATE SCHEMA powerbi ; Step 3 : Aiven's certificate. Download the CA cert from the Overview page: Now here's the part that actually tripped me up: Power BI's PostgreSQL connector doesn't ha

Why Your SOE Resume Needs a Structural Overhaul Chinese state-owned enterprises (SOEs) often have deep hierarchical structures and a culture of collective achievement. But Western tech companies want to see individual impact, autonomy, and data-driven results. Continuing to lead with your former employer's prestige or your rank (e.g., "Senior Engineer Grade 7") wastes valuable space. The solution: reshape every section to answer the question "What did you personally accomplish with data?" The Core Shift: From Hierarchy to Impact In a Chinese SOE resume, it's tempting to list departments you led or teams you oversaw. In a Western senior data scientist resume, focus on the problems you defined, the algorithms you deployed, and the revenue, cost savings, or user metrics that improved. For example, instead of "Led the data analytics team of 10 people," write "Designed and deployed a demand-forecasting model that reduced inventory costs by 15% (¥12M annually)." Three Resume Sections That Require Full Rewriting Professional Summary: From 'Accomplished Engineer' to 'Data Science Leader' Start with your total years of experience, your technical stack, and the types of business problems you solve. Example: "Senior Data Scientist with 10+ years applying machine learning to supply chain and logistics. Expertise in Python, TensorFlow, and Spark. Reduced operational costs by 15-30% through predictive models deployed at [SOE name]." Work Experience: From Role Descriptions to Metric-Driven Bullets For each role, list 3-5 bullets. Every bullet should have a verb, a task, a technology (if relevant), and a quantified result. Avoid vague phrases like "responsible for." Use specific numbers: "Improved forecast accuracy from 70% to 85% by building an ensemble of ARIMA and XGBoost models." Education & Certifications: Emphasize Transferable Skills Your Chinese degree is fine, but add relevant certifications (AWS, TensorFlow, Coursera) to show adaptability. Consider a "Technical Skills" se

Introduction Fixing N+1 queries with select_related / prefetch_related or selectinload (see the previous post ) gets you down to a small, sane number of queries per request. The next bottleneck is what each query costs once the table has millions of rows — and that is almost always about indexing. An index turns "scan every row" into "look it up directly." Skip it, and a query that's instant in development takes seconds once real data volume shows up in production. How Indexes Work: The B-Tree Intuition Without an index, a WHERE clause forces a sequential scan : the database reads every row and checks the condition — O(n) , cost grows linearly with table size. An index is a separate, sorted structure (almost always a B-tree ) mapping column values to row locations. Because it's sorted and balanced, finding a value is a tree walk: O(log n) . On a 10-million-row table, that's the difference between reading 10 million rows and roughly 23 tree nodes. This isn't free: Writes get slower — every INSERT / UPDATE / DELETE on an indexed column also updates the index. Storage grows — each index is a sorted copy of (part of) the data. An index trades write cost and storage for read speed. Indexing a column you rarely filter or sort on is pure cost, no benefit. Reading Query Plans: EXPLAIN ANALYZE Postgres' EXPLAIN ANALYZE shows what the planner actually did, not an estimate. Before an index , filtering orders by customer_id : EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 48291 ; Seq Scan on orders (cost=0.00..21453.00 rows=42 width=96) (actual time=0.021..118.442 rows=41 loops=1) Filter: (customer_id = 48291) Rows Removed by Filter: 1199959 Planning Time: 0.112 ms Execution Time: 118.471 ms Seq Scan means Postgres read all ~1.2 million rows and discarded all but 41. actual time is real elapsed time — 118ms for one lookup. After CREATE INDEX idx_orders_customer_id ON orders (customer_id); : Index Scan using idx_orders_customer_id on orders (cost=0.42..8.53 rows=42 wid

Introduction Fixing N+1 queries (see the previous post ) gets your Hibernate app down to a handful of queries per request. The next bottleneck is what each of those queries costs once your tables have millions of rows — and that is almost always a question of indexing. An index turns "scan every row" into "look it up directly." Get the index wrong — or skip it — and a query that took 2ms in development takes 4 seconds in production once real data volume shows up. How Indexes Work: The B-Tree Intuition Without an index, a WHERE clause forces a sequential scan : the database reads every row and checks the condition. That's O(n) — cost grows linearly with table size. An index is a separate, sorted data structure (almost always a B-tree ) that maps column values to row locations. Because it's sorted and balanced, finding a value is a tree walk: O(log n) . On a 10-million-row table, that's the difference between reading 10 million rows and reading roughly 23 tree nodes. The cost is not free: Writes get slower. Every INSERT / UPDATE / DELETE on an indexed column must also update the index structure. Storage grows. Each index is a copy of (part of) the data, sorted differently. An index is a trade: you pay on every write so that specific reads become fast. Indexing a column you rarely filter or sort on is pure cost with no benefit. Reading Query Plans: EXPLAIN ANALYZE Postgres' EXPLAIN ANALYZE shows what the planner actually did — not what you hope it did. Before an index , filtering orders by customer_id : EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 48291 ; Seq Scan on orders (cost=0.00..21453.00 rows=42 width=96) (actual time=0.021..118.442 rows=41 loops=1) Filter: (customer_id = 48291) Rows Removed by Filter: 1199959 Planning Time: 0.112 ms Execution Time: 118.471 ms Seq Scan means Postgres read all ~1.2 million rows and threw away all but 41 of them. actual time is the real elapsed time, not an estimate — 118ms for one lookup. After CREATE INDEX idx_orders

Cycle recently introduced a separate EU-based control plane, allowing European customers to keep platform management data and telemetry within Europe. The new offering is designed to improve compliance, operational isolation, and responsiveness for European organizations. By Renato Losio

Cloudflare details Town Lake, an internal unified data platform, and Skipper, an AI analytics agent unifying access to operational, billing, security, and business data. The platform processed ~91K billing queries, with billing forming majority usage. Built on a lakehouse architecture using Trino, Iceberg, R2, and DataHub, it enables governed cross-system analytics and natural language access. By Leela Kumili

Hardwood, the project Gunnar Morling kick-started handling of Parquet files in Java, reached version 1. Its multi-threaded approach and zero mandatory external dependencies promise a simpler, more efficient alternative to the Apache Parquet Java implementation. For now, the library supports just reading; writing support is expected in the upcoming versions. By Olimpiu Pop

Introduction As data volumes continue to grow, running aggregation queries directly on raw datasets becomes increasingly expensive. Business dashboards, analytics platforms, and reporting systems often execute the same calculations repeatedly—such as total sales, daily active users, page views, or revenue trends. While ClickHouse® is designed to process analytical workloads at remarkable speed, repeatedly scanning billions of records still consumes valuable CPU, memory, and storage resources. This is where AggregatingMergeTree proves its value. Rather than calculating aggregates every time a query is executed, AggregatingMergeTree stores intermediate aggregation states that are merged automatically in the background. This approach allows analytical queries to read compact, pre-aggregated datasets, resulting in dramatically faster response times and reduced infrastructure costs. In this guide, you'll learn how AggregatingMergeTree works, why aggregate states matter, how to build an automated aggregation pipeline using Materialized Views, and when this engine is the right choice for your ClickHouse® workloads. What is AggregatingMergeTree? AggregatingMergeTree is a specialized ClickHouse® table engine designed to store aggregate function states instead of raw records. Unlike the standard MergeTree engine, which stores every inserted row, AggregatingMergeTree keeps partially aggregated values that ClickHouse combines during background merge operations. This significantly reduces the amount of data that must be processed when generating analytical reports. Because much of the computational work happens during data ingestion, dashboards and reporting applications can retrieve summarized information much more efficiently. Typical scenarios include: Sales reporting Website traffic analytics Financial summaries IoT sensor monitoring Business KPI dashboards Application observability metrics Why Use AggregatingMergeTree? Imagine an online marketplace processing millions of tr

The speakers discuss Agent RFT, OpenAI’s platform for fine-tuning reasoning models via real-time tool interactions and custom reward signals. They explain how reinforcement learning solves complex credit assignment challenges within the context window. They share enterprise success stories, showing how Agent RFT eliminates long-tail token loops and drives extreme efficiency. By Wenjie Zi, Will Hang

If you ask any senior backend engineer or database administrator how to instantly make a slow, disk-bound application faster, their first answer is almost always: "Put it in memory." But why is memory so preferred, and how do modern architectures utilize RAM to achieve sub-millisecond latencies? We're seeing a massive revival of RAM disks and in-memory architectures. Let's explore why computer experts are increasingly treating RAM like a hard drive. 1. The Physics of Storage: Why RAM Wins To understand the shift towards in-memory architectures, we have to look at the numbers. Hard Disk Drives (HDDs): Mechanical spinning disks. Seek times are around 2-5 milliseconds . Solid State Drives (SSDs): Flash memory. Seek times are around 0.1 milliseconds (100 microseconds) . RAM (Random Access Memory): Volatile silicon. Access times are around 100 nanoseconds . RAM is roughly 1,000 times faster than an SSD and 10,000 to 50,000 times faster than an HDD. When you have a high-throughput system serving millions of requests per second, waiting for a disk to seek is an eternity. 2. In-Memory Databases: Redis and Memcached The most common implementation of this principle in modern backends is the In-Memory Database . How They Work Instead of writing every transaction to an SSD, systems like Redis and Memcached store the entire dataset directly in RAM. This bypasses the OS file system cache, disk I/O bottlenecks, and complex B-tree traversals required by traditional relational databases like PostgreSQL or MySQL. The Trade-off: Durability RAM is volatile. If the server loses power, all data is gone. So how do in-memory databases survive crashes? Snapshots (RDB in Redis): Periodically dumping the entire memory state to disk. Append-Only Files (AOF in Redis): Logging every write operation to a disk sequentially. Sequential writes to disk are significantly faster than random writes. This hybrid approach gives you the read/write speed of RAM with a "good enough" durability guarantee for

The Quest Begins (The "Why") I still remember the first time I faced a problem that asked for the sum of numbers in a sub‑array, over and over again, with updates sprinkled in between. It felt like I was stuck in a never‑ending loop of for i in range(l, r+1): total += arr[i] – O(n) per query, and with up to 10⁵ queries the solution timed out every single time. I was staring at the screen, thinking, “There has to be a smarter way to answer these range questions without scanning the whole array each time.” That moment was my dragon: a seemingly simple problem that kept biting me because I kept reaching for the brute‑force sword. I needed a data structure that could give me the answer in logarithmic time while still supporting point updates. Enter the segment tree – the tool that turned my O(n·q) nightmare into an O((n+q)·log n) victory. The Revelation (The Insight) So why does a segment tree work? Imagine you have an array and you want to know the sum of any interval [l, r] . If you could break that interval into a handful of pre‑computed chunks, you’d only need to add those chunk values together instead of touching every element. A segment tree is exactly that: a binary tree where each node stores the aggregate (sum, min, max, etc.) of a segment of the original array. The root covers the whole array [0, n‑1] . Its two children cover the left half and the right half, and this keeps splitting until the leaves represent single elements. The magic lies in two facts: Every node’s value is a function of its children. If you know the sum of the left child and the sum of the right child, the parent’s sum is just their addition. This means we can build the tree bottom‑up in O(n) time. Any interval can be represented as O(log n) disjoint nodes. When you walk down the tree to answer [l, r] , you either take a whole node (if its segment lies completely inside the query) or you recurse further. Because the tree’s height is log₂n, you’ll visit at most 2·log₂n nodes. Thus, building

Here is a question I could not answer from the headlines: which European countries are actually losing people the fastest, in absolute terms or per capita? Those are two different questions, and they give two different answers. So I pulled the open data and ran the numbers. The headline figure Across the 19 European countries in the 2024 dataset, 17 recorded a net loss of native-born residents . Only two were net positive. So the "brain drain" story is not a handful of outliers, it is the default state of the continent. But the interesting part is who tops the ranking, because it depends entirely on how you measure. Load the data yourself The dataset is public on GitHub (CC BY 4.0). Every number below is reproducible with a few lines of pandas. No download, no API key, it reads the raw CSV straight from the repo: import pandas as pd url = ( " https://raw.githubusercontent.com/DatapulseResearch/ " " brain-drain-eu/main/data/net_migration_native_born_2024.csv " ) df = pd . read_csv ( url ) print ( df . shape ) # (19, 3) print ( df . columns . tolist ()) # ['country', 'net_migration', 'per_1000_residents'] # How many countries lost native-born residents? losers = ( df [ " net_migration " ] < 0 ). sum () print ( f " { losers } of { len ( df ) } countries had a net loss " ) # 17 of 19 net_migration is the raw count for 2024 (negative means a net loss of native-born residents). per_1000_residents is the same flow normalized by population size. The absolute ranking: Germany runs away with it Sort by the raw count and one country dominates: worst_absolute = df . sort_values ( " net_migration " ). head ( 5 ) print ( worst_absolute [[ " country " , " net_migration " ]]) country net _ migration 0 Germany - 91067 ... Germany loses -91,067 native-born residents, far more than anyone else in absolute terms. If you stop reading here, the story writes itself: "Germany, Europe's biggest brain drain." Plenty of coverage did exactly that. The counterintuitive finding: the ranking inve