Strap in, this story in­volves a cheese for­tune teller, the de­part­ment of war, and nearly every other gov­ern­ment de­part­ment in be­tween.

Strap in, this story in­volves a cheese for­tune teller, the de­part­ment of war, and nearly every other gov­ern­ment de­part­ment in be­tween.

In 2017 (I think?) I was in­tro­duced to weather bal­loon hunt­ing by Mark VK5QI. At the time the Australian bal­loon chas­ing com­mu­nity was small. Only Melbourne and Adelaide ra­dioson­des (the trans­mit­ter on weather bal­loons) were be­ing tracked on a web­site called Habhub - high al­ti­tude bal­loon­ing hub. This site was de­signed for am­a­teur bal­loons and not me­te­o­ro­log­i­cal weather bal­loons.

Over time more and more ra­dioson­des were tracked on Habhub and even­tu­ally Habhub ad­mins in­tro­duced a de­fault fil­ter that re­moved weather bal­loons by de­fault. A query pa­ra­me­ter could be added to the URL to re­move the fil­ter and on 12th of May 2018 son­de­hub.org reg­is­tered with a sin­gle pur­pose - a URL redi­rect to Habhub with a ra­diosonde spe­cific fil­ter. To be clear - this was more of a joke than a de­ci­sion to run a ra­diosonde track­ing ser­vice. You’d go to son­de­hub.org and it would redi­rect you to hab­hub.org. That was it.

However Habhub was never de­signed for so many unique bal­loons each day. By July we de­cided to start prox­y­ing ra­diosonde in­ges­tion data through SondeHub. This al­lowed us to cap­ture more data as well (no longer rate lim­it­ing our selves). This went to a seper­ate OpenSearch clus­ter, how­ever at this stage we did­n’t use or ex­pose this data. I was us­ing this more as a toy - to play around with dif­fer­ent Amazon Web Services (AWS) ser­vices and an­a­lyt­ics plat­forms.

By 2019 the Habhub servers were re­ally strug­gling - aprs.fi as well. We re­alised that we needed to run our own ser­vice and our ini­tial plan was that we would build new APIs, and even­tu­ally new fron­tend. We then started get­ting in­for­ma­tion re­quests from gov­ern­ment agen­cies re­gard­ing ra­diosonde data. For ex­am­ple we re­ceived a re­quest re­gard­ing an in­sur­ance claim about a ra­dioson­des hit­ting a horse, caus­ing it to bolt through a fence. One of the rea­sons for this is be­cause un­like of­fi­cial soft­ware at the time, our sys­tem tracked the ra­dioson­des all the way to the ground.

Also in 2019 we de­tected a drop in ra­diosonde launches. This lined up with the GPS rollover date - we thought our soft­ware was bro­ken how­ever it turned out to be is­sues with Vaisala’s equip­ment which pre­vented launches from oc­cur­ing. Funnily enough our soft­ware han­dled the rollover ok.

In 2020/2021 we ended up do­ing was build­ing back­wards com­pat­i­ble APIs for the Habhub fron­tend and started test­ing the Habhub fron­tend pointed at our back­end. It mostly worked. We started re­ceiv­ing all the data rather than just par­tial data and pro­vid­ing open ac­cess to our data via S3. We even started run­ning our own pre­dic­tor - which is used by my en­ti­ties to­day.

With our own pre­dic­tor run­ning Mark de­vel­oped a sys­tem we call re­verse pre­dic­tions. This is where we take data from an al­ready launched ra­diosonde and use the wind model to run the pre­dic­tor back­wards which de­ter­mines a rough the launch lo­ca­tion pre­dic­tion. It works ex­tremely well. We could de­tect a bunch of ra­diosonde launch sites that were poorly oth­er­wise doc­u­mented along with start as­sign­ing bal­loons to launch sites.

Our first taste of deal­ing with the mil­i­tary

Then in 2021 we re­ceived an email

sen­si­tive/​mil­i­tary/… in­stal­la­tion. As such, we re­ally pre­fer that it is not ex­plic­itly marked on any map.

sen­si­tive/​mil­i­tary/… in­stal­la­tion. As such, we re­ally pre­fer that it is not ex­plic­itly marked on any map.

The thing is though that wind data is­n’t just used for pre­dict­ing the weather. It’s also used to cal­cu­late ar­tillery rang­ing. What we had started do­ing is ac­ci­den­tally map­ping out ar­tillery sites. We de­cided to keep re­verse pre­dic­tions but we delete launch sites on gen­uine re­quests.

The re­verse pre­dic­tion sys­tem has also de­tected many num­ber of mil­i­tary ves­sels in the ocean.

Lots more de­vel­op­ment hap­pened on SondeHub with fea­tures like web­sock­ets and MQTT for live feeds. We dis­con­nected Habhub back­end from our proxy and with grant fund­ing from ARDC we were able to setup a pro­to­type am­a­teur high al­ti­tude bal­loon ver­sion of SondeHub.

Eventually Habhub was shut­down due to a lack of main­te­nance and we rushed to­gether to mi­grate what we could to SondeHub.

$439,000 mis­sile vs party bal­loon

All was go­ing fine un­til the 2023 “China spy bal­loon” in­ci­dent. SondeHub had a lot more traf­fic - but our ar­chi­tec­ture made it fairly man­age­able.

Then Feb 11th 2023 the US al­legedly used AIM-9X Sidewinder to shot down an am­a­teur ra­dio bal­loon. That morn­ing I woke to high us­age alarms in my in­box. SondeHub had been linked to on the Washington Post. Our site man­aged to han­dled the ex­tra traf­fic rea­son­ably well.

Since then we’ve many sup­port re­quests from .mil and .gov ad­dresses. We’ve also had re­quests from avi­a­tion in­dus­try / air con­trol tow­ers.

In Dec 2024 - alarms in my in­box again. This time get­ting alarms for pre­dic­tions. Someone de­cided to smash our api. This seem­ingly starts hap­pen­ing every week.

Full scale in­va­sion

We turn on log­ging. The re­quests com­ing from a sin­gle IP. We had some sus­pi­cions that a pri­vate com­pany was us­ing our back­end to gen­er­ate pre­dic­tions. We poke their web­site to see - sure enough they are - an an­gry email to them. However they weren’t the prob­lem.

We ask some peo­ple.

Note that the pre­ci­sion of these points has been in­ten­tion­ally been re­duced. This data is also sig­nif­i­cantly old and does not show the en­tire dataset. This blog post has been de­layed un­til bal­loon war­fare was more com­mon knowl­edge.

Note that the pre­ci­sion of these points has been in­ten­tion­ally been re­duced. This data is also sig­nif­i­cantly old and does not show the en­tire dataset. This blog post has been de­layed un­til bal­loon war­fare was more com­mon knowl­edge.

Fuck. And Fuck Russia.

(for time trav­ellers and peo­ple in the fu­ture - in 2022 started a “special mil­i­tary op­er­a­tion” - aka a full scale in­va­sion into Ukraine. The war con­tin­ues at time of writ­ing. Fuck Russia)

Suddenly my mind was filled with ethic and le­gal ques­tions. We also sus­pected they aren’t us­ing the API cor­rectly. However we did­n’t know how to get in con­tact.

We did even­tu­ally got some mes­sages out via a con­tact

“We work with mHAB’s as you know, but some other groups likely fly fixed-wing and use Sondehub to help them “surf” the sky to tar­get ar­eas.

“We work with mHAB’s as you know, but some other groups likely fly fixed-wing and use Sondehub to help them “surf” the sky to tar­get ar­eas.

“Sent this in Ukrainian to a few milchats and will see what turns up: “I wish every­one good health. If any­one knows of a deep strike team that uses a python script with some open source wind fore­cast­ing en­gine, please con­tact me di­rectly. They are caus­ing nu­mer­ous prob­lems with queries, which can lead to them be­ing blocked and they need to take ac­tion to be able to con­tinue us­ing the pre­dic­tion sys­tem.””

“Sent this in Ukrainian to a few milchats and will see what turns up: “I wish every­one good health. If any­one knows of a deep strike team that uses a python script with some open source wind fore­cast­ing en­gine, please con­tact me di­rectly. They are caus­ing nu­mer­ous prob­lems with queries, which can lead to them be­ing blocked and they need to take ac­tion to be able to con­tinue us­ing the pre­dic­tion sys­tem.””

I also quickly rushed to­gether a docker com­pose file so any­one could quickly run their own pre­dic­tor that was­n’t re­liant on us.

Meanwhile (and you might have no­ticed me ask­ing for AWS help on fedi) we con­tacted AWS as the source IP was from an AWS net­work. It was very im­por­tant how­ever to make sure the AWS sup­port did not shut­down ac­cess.

Our mes­sag­ing in­cluded:

It is in­cred­i­bly im­por­tant that the http re­quest data is not dis­trib­uted. It is also im­por­tant that the source AWS ac­count is not blocked, rate lim­ited or ter­mi­nated - loss of life could oc­cur.

It is in­cred­i­bly im­por­tant that the http re­quest data is not dis­trib­uted. It is also im­por­tant that the source AWS ac­count is not blocked, rate lim­ited or ter­mi­nated - loss of life could oc­cur.

Something that I thought I’d never have to write in sup­port emails. The mes­sag­ing was im­por­tant be­cause I did not want the ser­vice cut off, and I did not want the data to re­veal launch sites.

After a bit of wait­ing we re­ceived:

AWS reached out to me that a lambda func­tion of mine was flagged for po­ten­tially scrap­ing api.v2.son­de­hub.org and they told me to reach out to you to get this re­solved.

AWS reached out to me that a lambda func­tion of mine was flagged for po­ten­tially scrap­ing api.v2.son­de­hub.org and they told me to reach out to you to get this re­solved.

We emailed back and forth and pro­vided doc­u­men­ta­tion on how to run the pre­dic­tor lo­cally.

Office of the Secretary of War (Intelligence and Security)

In 2025 we re­ceived a re­quest for data from the “Office of the Secretary of War (Intelligence and Security)” (US). Generally if there’s mu­tual com­mu­nity ben­e­fit we’ll find, process and re­lease the data for free. However given this is was the Department of War and no ex­pected com­mu­nity ben­e­fit we de­cided they should pay for the data. I was hes­i­tant even work­ing with them, as I don’t re­ally want to help mil­i­tary, let alone the US - but since our data is pub­lic if we did­n’t do it some­one else prob­a­bly would. So my rea­son­ing shifted to, may as well ex­tract some funds to pay for SondeHub in­fra­struc­ture at the very least.

An in­voice was cre­ated and sent through - but never paid or fol­lowed up on. I have no idea why they were re­quest­ing the data or what it was about.

Other tid­bits along the way

It has­n’t just been the mil­i­tary that we get emails from. Occasionally cit­i­zens who find ra­dioson­des end up con­tact­ing us (often we don’t know how they even find us), along with a range of other or­gan­i­sa­tions.

National Transportation Safety Board (US)

In September 2025 the NTSB con­tacted us. My first re­ac­tion was to search for news sto­ries.

do you have in­for­ma­tion on any bal­loons in the Utah are be­tween 1200 and 1300 UTC on 10/16/2025

do you have in­for­ma­tion on any bal­loons in the Utah are be­tween 1200 and 1300 UTC on 10/16/2025

We pro­vided our data but also started hear­ing some ru­mours about a pos­si­ble plane / weather bal­loon col­li­sion that was re­ported via ACARS. While none of the bal­loons tracked by SondeHub lined up, we did for­ward some in­for­ma­tion that a Windborne bal­loon was in the area. Windborne later con­firmed this was the likely col­li­sion and have made sev­eral changes to their sys­tem to pre­vent fu­ture is­sues.

We have a num­ber for you to call when you’re ready to copy

Please con­tact us as soon as prac­ti­ca­ble with more in­for­ma­tion… Contact our Operations Manager at

Please con­tact us as soon as prac­ti­ca­ble with more in­for­ma­tion… Contact our Operations Manager at

This was a re­ally strange in­ter­ac­tion for us. A tower(?) op­er­a­tions su­per­vi­sor was re­quest­ing in­for­ma­tion about bal­loons in the area. The bal­loons in ques­tion were me­te­o­ro­log­i­cal weather bal­loons. Not launched by am­a­teurs. We had to ex­plain that they are nor­mally sched­uled, not con­trolled, and fall (probably, not a lawyer) within Part 101.D of FAA regs. Along with that we did­n’t have con­tacts or reg­is­tra­tion de­tails of these launches.

We have a lot of Aircraft in the sky that don’t want to get too close to one of these bal­loons! Is there any way to co­or­di­nate more di­rectly with the con­trol­ling en­tity, or to have them give us mis­sion de­tails and con­tact in­for­ma­tion ahead of time? It sounds like you guys have a big op­er­a­tion, I don’t know if this is a one off event or if you have sys­tems in place to com­mu­ni­cate these things

We have a lot of Aircraft in the sky that don’t want to get too close to one of these bal­loons! Is there any way to co­or­di­nate more di­rectly with the con­trol­ling en­tity, or to have them give us mis­sion de­tails and con­tact in­for­ma­tion ahead of time? It sounds like you guys have a big op­er­a­tion, I don’t know if this is a one off event or if you have sys­tems in place to com­mu­ni­cate these things

Explaining to the FAA that weather bal­loons ex­ist was­n’t on my bingo card.

Hit and run

On 2/5 around 8pm was there a bal­loon lo­cated in Anamosa Iowa?

On 2/5 around 8pm was there a bal­loon lo­cated in Anamosa Iowa?

Someone re­cov­ered a ra­diosonde from a prop­erty but ran into a build­ing along the way. They left with­out leav­ing a note. The prop­erty owner con­tacted us for help to lo­cate the per­son.

Jam, tasty tasty jam

There’s a great site that uses ADSB data to track GPS jam­ming called gp­s­jam.org. We’ve also been de­tect­ing not only a lot of GPS jam­ming but also GPS spoof­ing. I al­ways find the pat­terns in­ter­est­ing. I’ve been pre­sum­ing that the pat­tern is ei­ther for mak­ing the im­pacted tar­gets eas­ier to iden­tify or to crash the ve­hi­cle in a spe­cific way?

The cheese for­tune teller and other job ti­tles we’ve seen over the years

Probably the most in­ter­est­ing job ti­tle we’ve had the plea­sure of read­ing in an email is from Jennifer Billock, Freelance Writer and Author, Certified Tea Specialist, Cheese Fortune Teller. Jennifer wrote an ar­ti­cle for STNDRDS about weather bal­loons which is out­side our usual places of ex­po­sure.

During this time we’ve seen many job ti­tles and sub­jects, I’ve started col­lect­ing them.

[SEC=🌶️🌶️🌶️]

Naval Air Warfare Center — Aircraft Division Maritime Patrol and Reconnaissance Aircraft (MPRA) Program

Acquisition Program Manager Integrated Processes Branch HQ AFRL/XPOP

Upper Air Quality Assurance Meteorologist Observing Systems & Operations, Data & Digital Group

Senior Advisor for Safety and Quality

Meteorologist Weather Forecast Office

Manager Upper Air Network

General Manager Observing Systems and Operations and Chief Engineer

Meteorologist National Weather Service

Field Research Manager, Center for Western Weather and Water Extremes

Video Journalist, Visual Investigations - NY Times

Senior Meteorologist, National Transportation Safety Board

Operations Supervisor U.S. Department of Transportation/FAA

STNDRDS Freelance Writer and Author, Certified Tea Specialist, Cheese Fortune Teller

Meteorológiai fe­jlesztő (met.hu)

SUNY Oswego Lab Technician Atmospheric and Geological Science

SpaceBalloon Project

Any many more

The weird

Most or­gan­i­sa­tion and ven­dors are will­ing to work with us. This is be­cause chas­ing ra­dioson­des re­moves them from the en­vi­ron­ment and pro­motes cit­i­zen sci­ence. I asked “Meteolabor AG” for one of their ra­dioson­des so that we could con­firm com­pat­i­bil­ity. This is what I re­ceived back.

Official re­sponse from Meteolabor AG: For strate­gic rea­sons, we do not pro­vide any data or sam­ple de­vices. Our trans­mit­ters shut down af­ter a cer­tain pe­riod of time, at the lat­est when the bat­tery ca­pac­ity is ex­hausted. This is due, among other things, to strate­gic con­sid­er­a­tions. We are aware of the so-called waste prob­lem.

Personal com­ment: I would per­son­ally like to draw at­ten­tion to mil­i­tary ac­tiv­i­ties, par­tic­u­larly in the Middle East, which re­sult in sig­nif­i­cantly (exponentially) more waste and toxic sub­stances be­ing re­leased into the at­mos­phere and left ly­ing around in the en­vi­ron­ment — or en­ter­ing the food and wa­ter cy­cles In ad­di­tion to mil­i­tary op­er­a­tions, count­less “missions” are cur­rently be­ing flown over Europe with the aim of leav­ing “contrails” in the sky [rather “chemtrails”]. I know their pur­pose; I know what NetZero is sup­posed to achieve, and what de­car­boniza­tion and CO2 re­duc­tion are in­tended to ac­com­plish. I am well-in­formed about the cli­mate hoax. Start there! The peo­ple to talk to are politi­cians, NGOs, and very wealthy old white men.

Official re­sponse from Meteolabor AG: For strate­gic rea­sons, we do not pro­vide any data or sam­ple de­vices. Our trans­mit­ters shut down af­ter a cer­tain pe­riod of time, at the lat­est when the bat­tery ca­pac­ity is ex­hausted. This is due, among other things, to strate­gic con­sid­er­a­tions.

We are aware of the so-called waste prob­lem.

Personal com­ment: I would per­son­ally like to draw at­ten­tion to mil­i­tary ac­tiv­i­ties, par­tic­u­larly in the Middle East, which re­sult in sig­nif­i­cantly (exponentially) more waste and toxic sub­stances be­ing re­leased into the at­mos­phere and left ly­ing around in the en­vi­ron­ment — or en­ter­ing the food and wa­ter cy­cles

In ad­di­tion to mil­i­tary op­er­a­tions, count­less “missions” are cur­rently be­ing flown over Europe with the aim of leav­ing “contrails” in the sky [rather “chemtrails”]. I know their pur­pose; I know what NetZero is sup­posed to achieve, and what de­car­boniza­tion and CO2 re­duc­tion are in­tended to ac­com­plish. I am well-in­formed about the cli­mate hoax.

Start there! The peo­ple to talk to are politi­cians, NGOs, and very wealthy old white men.

Which is… cer­tainly some­thing.

Onwards

Today, we are ex­cited to an­nounce that we are join­ing forces with Stripe, to power the next wave of GDP growth glob­ally.

OpenRouter is the first and largest model mar­ket­place and gate­way. We are the best way to dis­cover and use any AI model, with one in­ter­face, broad provider choice, model-ag­nos­tic ob­serv­abil­ity, cost man­age­ment, and rout­ing that im­proves price, per­for­mance, and up­time. We now process 10+ tril­lion to­kens per day from 400+ AI mod­els for a com­mu­nity of over 10 mil­lion de­vel­op­ers and com­pa­nies. Since our found­ing, we have seen at least 10x growth in in­fer­ence vol­ume every year.

We want to ex­plain why we made the de­ci­sion to join forces with Stripe and what it means for the mil­lions of de­vel­op­ers and com­pa­nies that build on us.

What this means for our users

OpenRouter will con­tinue to op­er­ate as it is: same mis­sion, same name, same prod­uct, same roadmap. If you build on OpenRouter to­day, noth­ing about your in­te­gra­tion changes.

OpenRouter ex­ists to give users every model on equal foot­ing, pro­vide open sig­nals about how they’re used in the mar­ket, help de­vel­op­ers or­ches­trate them to­gether, and make them ob­serv­able and man­age­able at scale. That com­mit­ment is core to how we op­er­ate, and it does­n’t bend to any model, any provider, or any par­ent com­pany. It also ex­tends to a grow­ing ecosys­tem of in­fer­ence-ad­ja­cent ser­vices, in­clud­ing AI-native web search, con­text man­age­ment, and more to come.

Routing de­ci­sions will re­main dri­ven by one thing: what’s best for you, the user.

Our mis­sion

We started OpenRouter in early 2023 on a sim­ple be­lief: in­tel­li­gence will be multi-model. No sin­gle model will win every task, and the fron­tier will move rapidly. That free­dom is crit­i­cal in­fra­struc­ture for the in­dus­try. AI is too im­por­tant for its fu­ture to be de­cided by whichever sin­gle model gets em­bed­ded first. AI has be­come the sin­gle largest dri­ver of eco­nomic growth in the US, and in­fer­ence is quickly be­com­ing the largest line item for every com­pany.

We en­vi­sion a healthy AI ecosys­tem where many mod­els thrive, where AI neu­ro­di­ver­sity is a strength, where a lab or an in­fer­ence provider with a break­through can reach mil­lions of de­vel­op­ers, and where no sin­gle model be­comes the de­fault by in­er­tia.

Our mis­sion is to re­al­ize this fu­ture, and it’s more im­por­tant than any­thing else. The op­por­tu­nity with Stripe al­lows us to ac­cel­er­ate it to­gether.

Why Stripe?

There are few com­pa­nies on earth we would have con­sid­ered sell­ing to; our mis­sion, our neu­tral­ity, and our lead in the mar­ket make the story for in­de­pen­dence strong. We would only join a com­pany if we thought we could do more to­gether, faster, with­out com­pro­mis­ing any of them.

Stripe is that com­pany. They are the best fi­nan­cial in­fra­struc­ture plat­form in the world. Their API set the stan­dard that de­vel­oper prod­ucts, in­clud­ing ours, have been mea­sured against ever since. This is a com­bi­na­tion of two plat­forms that de­vel­op­ers choose on merit, with cul­tures fo­cused on qual­ity, scale, and com­mit­ment to builders, and that will re­main es­sen­tial in a post-AGI econ­omy.

For years, OpenRouter has been called “Stripe for LLMs.” Both com­pa­nies share com­mon DNA: we ab­stract com­plex in­fra­struc­ture and mar­ket dy­nam­ics into de­light­ful APIs, and we ob­sess over the de­vel­oper and user on the other side of it. Businesses trust Stripe to op­ti­mize every part of their rev­enue stack, across pay­ment meth­ods, au­tho­riza­tion, fraud, and more. Builders, cus­tomers, model labs, and providers trust OpenRouter to run a neu­tral, re­li­able layer across a fast-mov­ing ecosys­tem.

Stripe brings a large cus­tomer net­work, data on how in­ter­net busi­nesses grow, and years of ex­pe­ri­ence run­ning trusted global in­fra­struc­ture. There is also no one bet­ter at man­ag­ing fraud and abuse, some­thing we be­lieve will only be­come more chal­leng­ing for AI com­pa­nies to ad­dress. We can now serve de­vel­op­ers at a pace we could­n’t reach alone.

What’s next

To our cus­tomers: Thank you. We’re hon­ored to be part of your jour­ney, and we’re just get­ting started. OpenRouter’s prod­uct, mis­sion, and cur­rent com­mit­ments re­main un­changed. Joining Stripe helps us pur­sue them faster, and our abil­ity to sup­port you will only im­prove.

To our em­ploy­ees: We firmly be­lieve that the next few years will be the most im­por­tant time of our lives, and the most im­por­tant for our mis­sion. We are so grate­ful to have the priv­i­lege of be­ing alive dur­ing this trans­for­ma­tion for the world, and that I get to do it with you. You are some of the most bril­liant, cre­ative, cu­ri­ous, and de­ter­mined peo­ple there are, and we’re ex­cited to grow our team for an even greater global im­pact.

To every­one else who be­lieves in our mis­sion: come join us. Fitting into a role is­n’t as im­por­tant as hav­ing our val­ues: cu­rios­ity, rigor, agency, and trans­parency. AI will trans­form the way com­pa­nies are or­ga­nized, and OpenRouter will in­no­vate sig­nif­i­cantly here. And as we grow, we will re­lent­lessly aim to pre­serve the ve­loc­ity, agility, ef­fi­ciency, and tal­ent den­sity of the 90-person startup that we are to­day.

— Alex, Chris, Louis, and the OpenRouter team

The trans­ac­tion is sub­ject to cus­tom­ary clos­ing con­di­tions. We ex­pect to close in the com­ing weeks.

The Go Blog

Today the Go team is pleased to re­lease Go 1.27. You can find its bi­nary archives and in­stallers on the down­load page.

Go 1.27 brings ma­jor en­hance­ments across the lan­guage, tool­chain, run­time, and stan­dard li­brary. Below are some of the key high­lights.

Language changes

Go 1.27 in­tro­duces three no­table up­dates to the lan­guage spec­i­fi­ca­tion.

First, generic meth­ods are now sup­ported. For ex­am­ple, see math/​rand/​v2.Rand:

// Prior to Go 1.27, a sep­a­rate method on Rand had to be added for each type // (unsigned in­te­ger meth­ods omit­ted for brevity). func (r *Rand) Int32N(n in­t32) in­t32 func (r *Rand) Int64N(n in­t64) in­t64 func (r *Rand) IntN(n int) int

// Go 1.27 adds a new generic method that works for all in­te­ger types. func (r *Rand) N[Int int­Type](n Int) Int

Second, a key in a struct lit­eral may now be any valid field se­lec­tor for the struct type, al­low­ing fields in nested or em­bed­ded structs to be ini­tial­ized di­rectly:

type Habitat struct { Burrow string }

type Gopher struct { Name string Habitat // Embedded struct. }

// Go 1.27 al­lows us­ing Burrow as a key di­rectly. g := Gopher{ Name: “Gopher”, Burrow: “Burrow #42″, }

Finally, func­tion type in­fer­ence has been gen­er­al­ized to ap­ply in all as­sign­ment con­texts. Generic func­tions can now be used with­out ex­plicit type ar­gu­ments in com­pos­ite lit­er­als, type con­ver­sions, and chan­nel sends:

func GenericFormatter[T any](v T) string { re­turn fmt.Sprintf(“value: %v”, v) }

type IntFormatter func(int) string

// Go 1.27 in­fers T = int in com­pos­ite lit­er­als, con­ver­sions, and chan­nel sends. for­mat­ters := []IntFormatter{GenericFormatter} fn := IntFormatter(GenericFormatter) ch := make(chan IntFormatter, 1) ch <- GenericFormatter

Tool im­prove­ments

go fix in­cludes sev­eral new mod­ern­iz­ers: atom­ic­types, em­bedlit, slices­back­ward, and un­safe­funcs.

go doc now sup­ports pack­age@ver­sion queries such as go doc ex­am­ple.com/​pkg@v1.2.3.

go mod tidy now au­to­mat­i­cally con­sol­i­dates mul­ti­ple re­quire blocks in go.mod into a stan­dard di­rect and in­di­rect two-block struc­ture.

Performance and run­time

Size-specialized mem­ory al­lo­ca­tion re­duces small ob­ject (<80B) al­lo­ca­tion costs by up to 30%, im­prov­ing over­all per­for­mance by ~1% for al­lo­ca­tion-heavy pro­grams.

The gor­ou­tine­leak pro­file in run­time/​pprof is now gen­er­ally avail­able, al­low­ing au­to­matic de­tec­tion of per­ma­nently blocked gor­ou­tines.

Standard li­brary ad­di­tions

en­cod­ing/​json/​v2 pro­vides high-level JSON pro­cess­ing with con­fig­urable op­tions and stricter de­faults, along­side en­cod­ing/​json/​json­text for low-level stream­ing. The ex­ist­ing en­cod­ing/​json pack­age is now backed by the v2 im­ple­men­ta­tion for faster un­mar­shal­ing while main­tain­ing back­wards com­pat­i­bil­ity.

crypto/​mldsa im­ple­ments the post-quan­tum ML-DSA sig­na­ture scheme (FIPS 204), in­te­grated into crypto/​x509 and crypto/​tls.

uuid pro­vides na­tive sup­port for gen­er­at­ing and pars­ing UUIDs.

simd and ar­chi­tec­ture-spe­cific simd/​arch­simd pro­vide ex­per­i­men­tal SIMD sup­port.

net/​http/​httptest adds NewTestServer, pro­vid­ing an in-mem­ory fake net­work suit­able for use with the test­ing/​synctest pack­age.

Please read the Go 1.27 re­lease notes for the com­plete list of changes and de­tails.

Over the next few weeks, fol­low-up blog posts will cover some of the top­ics rel­e­vant to Go 1.27 in more de­tail. Check back later to read those posts.

Thanks to every­one who con­tributed to this re­lease by writ­ing code, fil­ing bugs, try­ing out ex­per­i­men­tal ad­di­tions, and test­ing re­lease can­di­dates. As al­ways, if you no­tice any prob­lems, please file an is­sue.

We hope you en­joy us­ing Go 1.27!

To use the Mastodon web ap­pli­ca­tion, please en­able JavaScript. Alternatively, try one of the na­tive apps for Mastodon for your plat­form.

For years, many em­ploy­ers have wor­ried that work-from-home arrange­ments leave em­ploy­ees iso­lated, dis­con­nected from cowork­ers and more likely to leave their jobs.

But ac­cord­ing to a new study, re­mote work­ers are do­ing bet­ter than many em­ploy­ers re­al­ize.

Researchers an­a­lyzed sur­vey data from 7,704 em­ploy­ees at a large health­care or­ga­ni­za­tion. One pat­tern stood out: Employees who worked fully re­motely re­ported the high­est lev­els of well-be­ing, while those who worked en­tirely on­site re­ported the low­est. The study also found lit­tle ev­i­dence that re­mote work­ers felt less con­nected to col­leagues or work­place cul­ture.

“This sug­gests you let peo­ple work re­motely if they want to work re­motely,” said Ste­fanie Johnson, pro­fes­sor of or­ga­ni­za­tional lead­er­ship and in­for­ma­tion an­a­lyt­ics at the Leeds School of Business and co-au­thor of the study, pub­lished in July 2026 in the jour­nal Fron­tiers in Psychology. “Taking away peo­ple’s choice of how they work is prob­a­bly not go­ing to help them in terms of their well-be­ing.”

Stefanie Johnson

As com­pa­nies con­tinue to de­bate re­mote work, many lead­ers worry that em­ploy­ees need to be in the of­fice to stay con­nected, work well to­gether and re­main com­mit­ted to their or­ga­ni­za­tion. Johnson said the re­search does­n’t al­ways sup­port those con­cerns.

“The data from our study and oth­ers sug­gest re­mote and hy­brid work re­sult in bet­ter out­comes than re­turn-to-of­fice man­dates,” she said. “Leaders are not mak­ing de­ci­sions based on data. I think they are just re­turn­ing to what they are used to.”

Rethinking re­mote work

Johnson, who co-au­thored the study with Alyssa Lezcano, Stephanie Zajac and Courtney Holladay of the MD Anderson Leadership Institute in Houston, said the re­sults sur­prised her. She thought em­ploy­ees who split their time be­tween home and the of­fice might have the best of both worlds.

“I ac­tu­ally thought you would be hap­pi­est if you were part time out of the of­fice,” she said. “Then every once in a while you get to see peo­ple, get that hu­man con­nec­tion.”

Instead, the data pointed in a dif­fer­ent di­rec­tion.

Among em­ploy­ees in the study, well-be­ing was high­est for fully re­mote work­ers, fol­lowed by hy­brid em­ploy­ees and then on­site work­ers.

The find­ings also cast doubt on one of the main ar­gu­ments for bring­ing em­ploy­ees back to the of­fice: that peo­ple need to be to­gether in per­son to feel con­nected.

Employees in the study were asked to de­scribe their or­ga­ni­za­tion’s cul­ture in a hand­ful of words. Remote work­ers were slightly more likely than their hy­brid and on­site peers to use words as­so­ci­ated with team­work, in­clu­sion and sup­port.

“People who are re­mote ac­tu­ally said more things that in­di­cated they had more pos­i­tive con­nec­tions, even though they were re­mote,” Johnson said.

Still, Johnson said face-to-face in­ter­ac­tion can play an im­por­tant role in help­ing cowork­ers build re­la­tion­ships, es­pe­cially if they are just start­ing out in their ca­reers.

“Remote works bet­ter af­ter you know peo­ple,” she said. “So there is still a ben­e­fit of hav­ing some face time.”

Staying power

The re­searchers also ex­am­ined em­ployee turnover one year af­ter the sur­vey was com­pleted.

They found that em­ploy­ees with higher well-be­ing were less likely to leave the or­ga­ni­za­tion. Work lo­ca­tion it­self was not a strong di­rect pre­dic­tor of turnover. Instead, re­mote work was as­so­ci­ated with higher well-be­ing, which in turn was as­so­ci­ated with lower turnover.

“It makes sense. If you have higher well-be­ing, you’re less likely to leave your job,” Johnson said.

Participants com­pleted the work­place sur­vey in 2023, and re­searchers com­pared those re­sponses with ac­tual turnover records one year later. Of the em­ploy­ees sur­veyed, roughly half worked on­site, with the re­main­der split be­tween hy­brid and fully re­mote arrange­ments.

Flexibility mat­ters

The study did not ex­plore why re­mote work­ers re­ported higher well-be­ing, but Johnson points to a grow­ing body of re­search on au­ton­omy and flex­i­bil­ity.

One ex­pla­na­tion is that re­mote work­ers have greater con­trol over their work setup and daily sched­ule, she said.

“If you have con­trol over your en­vi­ron­ment, you tend to have more pos­i­tive out­comes,” she said.

Working from home can also elim­i­nate many every­day stres­sors.

“Spending a lot of time in traf­fic is neg­a­tively re­lated to well-be­ing,” Johnson said. “There are so many lit­tle stres­sors as­so­ci­ated with be­ing in the of­fice.”

Those stres­sors can in­clude ar­rang­ing child care, hir­ing help for pets or man­ag­ing the lo­gis­tics of get­ting to and from work, she said.

Johnson said the study points to a broader les­son for em­ploy­ers nav­i­gat­ing re­turn-to-of­fice de­bates. Rather than fo­cus­ing only on where em­ploy­ees work, or­ga­ni­za­tions may get bet­ter re­sults by in­vest­ing in em­ployee well-be­ing.

“I think flex­i­bil­ity is here to stay,” she said.

To use the Mastodon web ap­pli­ca­tion, please en­able JavaScript. Alternatively, try one of the na­tive apps for Mastodon for your plat­form.

gral­hix004 | Geolocating Random Islet Image Using Geometry & CUDA GPU Programming

16 – 08-2026 NOTE: this is a gen­uine hu­man work, didnt use LLM gen­er­a­tion.

16 – 08-2026

NOTE: this is a gen­uine hu­man work, didnt use LLM gen­er­a­tion.

I’m writ­ing this page as a writeup for this chal­lenge gral­hix 004 made by Sofia Santos | Gralhix.

You can view, clone and lo­cally try all code files and the fi­nal re­port with all in­struc­tions here at github.

You can view, clone and lo­cally try all code files and the fi­nal re­port with all in­struc­tions here at github.

Task brief­ing:

This is a photo of a re­sort lo­cated on an is­land.

a) What is the name of the re­sort? b) What are the co­or­di­nates of the is­land? c) In which car­di­nal di­rec­tion was the cam­era fac­ing when the photo was taken?

a) What is the name of the re­sort? b) What are the co­or­di­nates of the is­land? c) In which car­di­nal di­rec­tion was the cam­era fac­ing when the photo was taken?

In my opin­ion, solv­ing this chal­lenge with google lens is wast­ing a fun op­por­tu­nity, so de­cided to solve it with math and pro­gram­ming.

a] Metadata

Of course, first thing u look for is the meta­data. Ran that on my linux void:

> exiftool main.png

File Type  : WEBP (lossless) MIME Type  : im­age/​webp Image Width  : 736 Image Height  : 515

As ex­pected, noth­ing use­ful here. No EXIF, no GPS, no cam­era make or model.

b] Building the fin­ger­print

U can see from the img, there are 3 land­masses:

P0: the islet it­self,

P1: the right is­land,

P2: the left front is­land ( hav­ing moun­tain peak )

I couldnt make a cor­rect per­spec­tive model of bird­view of this im­age, as clearly the im­age is taken by a drone and cant es­ti­mate the el­e­va­tion at all (and not found in the meta­data).

So I had to es­ti­mate that by in­tu­ition, I just want the rel­a­tive dis­tances be­tween the 3 is­lands and an­gles of that tri­an­gle.

I built a small click GUI 01_triangle_gui.py that records pixel co­or­di­nates for each point in or­der and com­putes the tri­an­gle’s geom­e­try.

Since click­ing ex­act cen­ters by eye is­n’t per­fectly pre­cise, I added a ±20% tol­er­ance band around both val­ues when search­ing.

c] SEARCH

With the fin­ger­print locked in, the next step is check­ing every real land­mass on Earth against it !

I used OpenStreetMap’s split land poly­gon set as the dataset land-poly­gons-split-4326, full global coast­line vec­tors in WGS84 which has size of 882 MB.

I used OpenStreetMap’s split land poly­gon set as the dataset land-poly­gons-split-4326, full global coast­line vec­tors in WGS84 which has size of 882 MB.

I cre­ated heuris­tic fil­ters (all by just in­tu­ition and non tan­gi­ble proofs), spent days (yea full days) tweak­ing val­ues and tons of trial and er­ror 😭 un­till I got this work­ing fil­ters recipe.

01] Tropical lat­i­tude bound­ing box

$$ -30° \le lat­i­tude \le 30° $$

the islet in the photo reads as trop­i­cal, so I de­cided that any­thing out­side the trop­ics is thrown out im­me­di­ately, be­fore do­ing any ex­pen­sive geom­e­try work.

Exactly 141,131 land poly­gons sur­vive that band fil­ter.

Exactly 141,131 land poly­gons sur­vive that band fil­ter.

02] Local den­sity fil­ter

$$ N_{5\text{km}}(p) \le 10 $$

$ N_{5\text{km}}(p) $ counts how many other cen­troids fall within 5km of point (p). Cap is 10: if an islet has more than 10 neigh­bors that close, it’s sit­ting in a dense reef field, a crowded coast­line or a arch­i­pel­ago clut­ter, not a small iso­lated 3 – 4 is­land group like the photo shows.

This dropped can­di­dates down to 51,576.

This dropped can­di­dates down to 51,576.

03] Clustering

For every sur­viv­ing point, find every other point within 20km (heuristic, by eye from the im­age). If it has at least 2 neigh­bors that close (3 points to­tal), it’s a clus­ter. Points with no clus­ter of 3+ nearby are dropped, they can’t form a tri­an­gle at all.

tree = cK­DTree(f_­co­ords) neigh = tree.query_bal­l_­point( f_­co­ords, CLUSTER_RADIUS_KM / 111.0) clus­ters = set(tu­ple(sorted(n)) for n in neigh if len(n) >= 3)

$$ \left|\{q : \text{dist}(p,q) \le 20\,\text{km}\}\right| \ge 3 $$

That col­lapses down to 23,500 clus­ters.

That col­lapses down to 23,500 clus­ters.

04] Generating Triplets

For every clus­ter, every com­bi­na­tion of 3 points in­side it be­comes a can­di­date tri­an­gle. That’s $ C(n, 3) $, which ex­plodes fast for big clus­ters, for ex­am­ple: a clus­ter of 60 points al­ready gives 34,220 triples on its own. So each clus­ter gets capped at 60 points first, sam­pled by size, not ran­domly.

$$ \binom{n}{3} = \frac{n(n-1)(n-2)}{6} $$

def strat­i­fied_sam­ple(idx_arr, area_arr, cap): or­der = np.argsort(area_arr[idx_arr]) n_s­mall = cap // 3 n_large = cap // 3 n_mid = cap - n_s­mall - n_large mid_s­tart = max(0, (len(idx_arr) - n_large - n_mid) // 2) keep = np.unique(np.con­cate­nate([ or­der[:n_s­mall], or­der[-n_large:], or­der[mid_s­tart:mid_s­tart + n_mid], ])) re­turn idx_arr[keep]

def gen_­clus­ter_triples(idx_arr): lo­cal = np.ar­ray(list( iter­tools.com­bi­na­tions(range(len(idx_arr)), 3)), dtype=np.in­t64) re­turn idx_arr[lo­cal]

The sam­pling takes a third small is­lands, a third large, a third from the mid­dle of the size dis­tri­b­u­tion, in­stead of the full clus­ter or a ran­dom cut.

23,500 clus­ters pro­duce 80,690,777 triples to­tal !!

23,500 clus­ters pro­duce 80,690,777 triples to­tal !!

05] Matching, on the GPU

I gave every triple one CUDA thread. Each thread sorts its 3 points by land area to pick out P0 (smallest, the re­sort islet), then uses the wind­ing di­rec­tion of the other two to as­sign P1 and P2:

long long i = block­Idx.x * (long long)block­Dim.x + threa­dIdx.x; if (i >= n_triples) re­turn;

int pos[3] = {0, 1, 2}; for (int a1 = 1; a1 < 3; a1++) { int key = pos[a1]; dou­ble key­val = a[key]; int j = a1 – 1; while (j >= 0 && a[pos[j]] > key­val) { pos[j + 1] = pos[j]; j–; } pos[j + 1] = key; }

P1 vs P2 comes from a 2D cross prod­uct, no branch­ing on which clus­ter the triple came from, just the sign:

$$ \text{cross} = x_a y_b - x_b y_a $$ $$ P1 = \begin{cases} a & \text{cross} > 0 \\ b & \text{cross} \le 0 \end{cases} $$

Walk from P0 to a, then to b. If cross > 0, that’s a left turn (counterclockwise). If cross < 0, it’s a right turn (clockwise). It’s the same sign trick used to tell if 3 points curve one way or the other.

then an­gle at P0 and the dis­tance ra­tio, same for­mu­las as the fin­ger­print step, com­puted in­de­pen­dently by every thread:

$$ \theta_0 = \arccos\left(\frac{\vec{d_1} \cdot \vec{d_2}}{|\vec{d_1}||\vec{d_2}|}\right), \qquad r = \frac{|\vec{d_1}|}{|\vec{d_2}|} $$

A triple sur­vives if an­gle, ra­tio, P0′s size, the sep­a­ra­tion be­tween P0 and P1, and both side lengths all land in­side the fin­ger­print’s tol­er­ance win­dows. Threads that pass write their re­sult into a shared out­put ar­ray us­ing an atomic counter, so two threads fin­ish­ing at the same time never over­write each other:

if (hit) { un­signed long long slot = atom­i­cAdd(out­_­count, 1ULL); out­_p0[slot] = p0idx; out­_p1[slot] = p1idx; out­_p2[slot] = p2idx; }

Now printed in the CLI di­rectly from the ker­nel:

gpu: NVIDIA GeForce RTX 3050 (sm_86) vram used: 5169 MB ker­nel time: 204.1 ms

80.7 mil­lion triples go in, one thread each, in par­al­lel. 158,784 pass the mask.

80.7 mil­lion triples go in, one thread each, in par­al­lel. 158,784 pass the mask.

06] Dedup

Since same phys­i­cal triple can get hit by mul­ti­ple GPU threads if it be­longed to more than one over­lap­ping clus­ter, so raw matches get col­lapsed by iden­tity first:

seen = set() uniq = [] for i in range(len(p0_all)): key = (p0_all[i], p1_all[i], p2_all[i]) if key not in seen: seen.add(key) uniq.ap­pend(i)

8,915 unique triples af­ter dedup.

8,915 unique triples af­ter dedup.

07] The Open Rectangle

Every sur­viv­ing triple gets one more test: is the space next to it ac­tu­ally open wa­ter, like the photo shows ? A rec­tan­gle gets built along the P0→P1 edge, on whichever side P2 is not on, then checked against the land dataset for any­thing else sit­ting in­side it.

width = np.hy­pot(x1, y1) u = np.ar­ray([x1, y1]) / width v = np.ar­ray([-u[1], u[0]])

# p2 sits on the +v side by con­struc­tion, # so the check goes on -v length = 2 * width cor­ner­s_lo­cal = [ (0, 0), (x1, y1), (x1 - v[0]*length, y1 - v[1]*length), (-v[0]*length, -v[1]*length), ]

If any­thing other than the 3 can­di­date is­lands them­selves in­ter­sects that rec­tan­gle, the can­di­date is dropped. Land sit­ting there means it’s not the open, un­ob­structed wa­ter the photo ac­tu­ally shows.

8,915 unique triples down to 948.

8,915 unique triples down to 948.

and be­low is the map of places of the 948 can­di­dates.

d] Coral Cay Shape Check

In this stage, we look only at P0, the re­sort islet, and check whether its shape ac­tu­ally looks like a coral cay.

1] Compactness, how close to a cir­cle the shape is:

Polsby Popper Score: $$ PP = \frac{4\pi \cdot \text{area}}{\text{perimeter}^2} $$

def com­pact­ness(row): re­turn (4 * np.pi * row.area_km2) / (row.perim_km ** 2 + 1e-12)

1.0 is a per­fect cir­cle, lower means a more jagged or elon­gated out­line. Coral cays tend to be round from wave de­po­si­tion, so any­thing < 0.5 gets dropped.

2] Micro Cay Halo Check:

def mi­cro_­cay_­count(gdf, sin­dex, lon, lat): dist­s_km = nearby.geom­e­try.dis­tance(pt) * 111.0 mask = (dists_km > 0) & (dists_km <= HALO_KM) & (nearby[“area_km2”].values < MICRO_KM2) re­turn int(mask.sum())

We Count land frag­ments un­der 0.05 km² within 1.5km of P0 ( just heuris­tic ). Real reef sys­tems scat­ter tiny sand­bars around the main is­land, not just one iso­lated land­mass (I knew that with the hard­way 😭). So we need at least 1.

213/948 can­di­dates sur­vive both checks.

213/948 can­di­dates sur­vive both checks.

e] Oval Shape Check

Another geo­met­ric fil­ter on P0′s own poly­gon. Fits the min­i­mum ro­tated rec­tan­gle around it and mea­sures two ra­tios from that box.

def as­pec­t_and_­fill(geom): mrr = geom.min­i­mum_ro­tat­ed_rec­tan­gle co­ords = list(mrr.ex­te­rior.co­ords) s1 = math.hy­pot(co­ords[1][0] - co­ords[0][0], co­ords[1][1] - co­ords[0][1]) s2 = math.hy­pot(co­ords[2][0] - co­ords[1][0], co­ords[2][1] - co­ords[1][1]) long_­side, short­_­side = max(s1, s2), min(s1, s2) re­turn long_­side / short­_­side, geom.area / mrr.area

Aspect ra­tio is long side over short side of that box:

$$ \text{aspect} = \frac{\text{long side}}{\text{short side}} \in [1.05,\ 2.2] $$

Too close to 1.0 and it’s ba­si­cally a per­fect cir­cle, not the slightly elon­gated shape in the photo. Too high are shapes too much elon­gated more than 2:1.

Imagine, just for a mo­ment, that the Government wanted to keep a record of every­one’s sex­u­al­ity. They need to know this de­tailed de­mo­graphic data be­cause it will be highly use­ful in civic plan­ning. It will help them work out what pro­vi­sion needs to be made for sex­ual health ser­vices, how many chil­dren are likely to be born, how many schools to build, etc.

You trust the Government, you voted for them, you and your friends have noth­ing to hide with re­gards to your sex­u­al­ity.

But! Shock hor­ror! After cre­at­ing the data­base, the Government loses the elec­tion and the ho­mo­phobes at UKIP get in to power!

Now they have a data­base of every gay in the vil­lage, and can ha­rass then, try to “cure” them, or make their lives a liv­ing hell.

Far fetched? Not re­ally. With Cameron’s inane web fil­ter­ing plan, the “black boxes” in ISPs which can record every click you make, and the sell­ing of the your NHS de­tails to pri­vate par­ties, we’re in a sit­u­a­tion where a ma­li­cious gov­ern­ment could cause se­ri­ous dam­age to us.

The se­cu­rity ex­pert Bruce Schneier wrote a won­der­ful ar­ti­cle for CNN on how the ex­ist­ing sur­veil­lance state is lead­ing to dis­as­trous breaches of our pri­vate in­for­ma­tion. He con­cludes by say­ing:

It’s bad civic hy­giene to build tech­nolo­gies that could some­day be used to fa­cil­i­tate a po­lice state.

– Bruce Schneier on CNN

It’s bad civic hy­giene to build tech­nolo­gies that could some­day be used to fa­cil­i­tate a po­lice state.

– Bruce Schneier on CNN

We have to be care­ful that the ap­pa­ra­tus we build can­not eas­ily be mis­used for evil pur­poses. Sure, even an in­nocu­ous toaster can be weaponised if some­one is will­ing enough, but we should not fall into the trap of mak­ing sys­tems which can eas­ily be turned against the peo­ple.

It’s prob­a­bly sen­si­ble to build a data­base of which car be­longs to which owner - it has an im­por­tant civil use and would be hard to abuse (although not im­pos­si­ble).

Should we have a na­tional data­base of, say, re­li­gious be­liefs? Almost in­stinc­tively the an­swer is no. The mem­o­ries of fas­cist dic­ta­tors haunt our col­lec­tive con­scious­ness. We have seen count­less times how race and re­li­gious iden­tity be­come death penal­ties. We would­n’t coun­te­nance it.

Civic hy­giene is­n’t about say­ing we dis­trust our cur­rent gov­ern­ment - it’s about not trust­ing the next gov­ern­ment.

Reference #18.7132817.1787215257.d212691

https://​er­rors.edge­suite.net/​18.7132817.1787215257.d212691

Contrary to pop­u­lar be­lief - the an­swer to every­thing is NOT 42 - it’s PostgreSQL. (ok. It might also be Postgres).

Table Of Contents

Intro

Rock Solid and Stable

Easy to Run, Install and Scale

Simplifies Your IT SetupPostgreSQL Replaces Solr and Elastic: Full-Text SearchPostgreSQL re­places MongoDB: Excellent Json SupportPostgreSQL re­places Kafka and RabbitMQ: PostgreSQL as a queue­Post­greSQL Replaces Clickhouse: High Volume Time Series DataPostgreSQL as Vector Database for AI WorkflowsPostgreSQL Replaces Redis: Non-Persistent High Performance CachingPostgreSQL Replaces File System: For Raw DataPostgreSQL Replacing Your Graph DatabasePostgreSQL Replacing Your MicroservicePostgreSQL - Replacing your Playstation 5

PostgreSQL Replaces Solr and Elastic: Full-Text Search

PostgreSQL re­places MongoDB: Excellent Json Support

PostgreSQL re­places Kafka and RabbitMQ: PostgreSQL as a queue

PostgreSQL Replaces Clickhouse: High Volume Time Series Data

PostgreSQL as Vector Database for AI Workflows

PostgreSQL Replaces Redis: Non-Persistent High Performance Caching

PostgreSQL Replaces File System: For Raw Data

PostgreSQL Replacing Your Graph Database

PostgreSQL Replacing Your Microservice

PostgreSQL - Replacing your Playstation 5

Conclusion

Intro

I started us­ing PostgreSQL roughly in 2003 for a re­search pro­ject called ColumbaDB. Columba is no more, but PostgreSQL is still alive and kick­ing more than ever.

In 2003, MySQL was much more widely used than PostgreSQL. MySQL was also po­ten­tially faster as it did not im­ple­ment all fea­tures of the SQL stan­dard. At the same time MySQL was lack­ing many fea­tures that we needed (full-text search, pow­er­ful in­dexes, SQL stan­dard com­pli­ance etc). PostgreSQL felt more like a “real” data­base in com­par­i­son to MySQL - like a tiny ver­sion of Oracle - but in open source clothes.

During that re­search pro­ject I learned a lot about data­bases, in­dexes and the power of PostgreSQL. One im­por­tant use-case was full-text search. We could have used MySQL in con­junc­tion with an­other sys­tem like Lucene / Solr to make our data­base search­able. But that would have meant run­ning and main­tain­ing two such sys­tems. Complicated.

PostgreSQL al­lowed us to use a full­text search plu­gin to do every­thing in one sys­tem. No need to sync any data. No need to main­tain and run two sys­tems. It just worked and made us smile (after some tweaks of course). Simplicity.

Since then I used PostgreSQL for many use-cases through­out my ca­reer as CTO / Interim Manager. Most re­cently I used PostgreSQL to store very high vol­ume web an­a­lyt­ics time se­ries data via its TimescaleDB plu­gin. Check out Privatracker - the best way to do web an­a­lyt­ics and re­spect the pri­vacy of your vis­i­tors - to see it in ac­tion.

Many oth­ers dis­cussed the topic from dif­fer­ent an­gles. And each ar­ti­cle is re­ally worth your time (SQL is Agile, Stephan Schmidt on Using SQL for Everything). Also check out my Linkedin post.

And if you are us­ing PostgreSQL I can highly rec­om­mend read­ing Hazel Bachrach’s nice post on “What I Wish Someone Told Me About Postgres”.

In my hum­ble opin­ion the power of PostgreSQL comes from three sources:

It is rock-solid and sta­ble.

It is easy to run, in­stall and scale.

It mas­sively sim­pli­fies your IT setup by be­ing not only a RDBMS, but also a full-text search en­gine, a doc­u­ment stor­age and much much more…

Let’s have a closer look…

Rock Solid and Stable

PostgreSQL is bor­ing old tech­nol­ogy. The first PostgreSQL re­lease dates back to 1996. PostgreSQL is also very widely used - for a very long amount of time. Ironing out bugs - es­pe­cially in data­base sys­tems - takes time. PostgreSQL had that time.

It also has a very ac­tive com­mu­nity that dili­gently adds more and more fea­tures with­out break­ing any old parts of it. In re­cent years PostgreSQL got many amaz­ing fea­tures like json doc­u­ment stor­age, par­ti­tion­ing sup­port, com­mon table ex­pres­sions and much much more. Each new re­lease of PostgreSQL is ex­cit­ing and brings new nice fea­tures.

True - PostgreSQL is old - but the fea­tures are very very mod­ern - and PostgreSQL be­comes bet­ter with every re­lease.

Easy to Run, Install and Scale

PostgreSQL can be in­stalled very eas­ily lo­cally. It is bun­dled with all ma­jor Linux dis­tri­b­u­tions, part of Mac brew, but can also be in­stalled with ap­pli­ca­tions like PostgresApp.

When run­ning tests, it comes in handy us­ing Testcontainers with PostgreSQL. It was never eas­ier run­ning your tests against a real PostgreSQL data­base that is 100% sim­i­lar to the pro­duc­tion thing.

If you want to run PostgreSQL on a server then you can sim­ply apt-get in­stall it. Or run it in a docker con­tainer.

All cloud providers al­low you to run (and scale!) PostgreSQL by click­ing a sin­gle but­ton. You got am­ple of choice at your fin­ger­tips:

Amazon AWS

Google GCP

Microsoft Azure

ElephantSQL

CrunchyData

Timescale

… and many more …

That makes PostgreSQL one of the most widely sup­ported soft­ware sys­tems in the mar­ket. And for you this means less main­te­nance and more time for cre­at­ing new fea­tures for clients.

Simplifies Your IT Setup

Running PostgreSQL in the cloud is al­ready just one click. But it gets even bet­ter. PostgreSQL can re­place many sys­tems that youd’d have to run oth­er­wise.

PostgreSQL Replaces Solr and Elastic: Full-Text Search

PostgreSQL al­lows you to turn your text data into user-search­able data. Without a sep­a­rate sys­tem. It’s also lan­guage ag­nos­tic and you’ll never have any sync prob­lems be­tween your data and your full­text search sys­tem.

The most im­pres­sive ar­ti­cle on the topic is how Contentful used PostgreSQL to en­able full­text search for their users. It’s a tale in sim­plic­ity that en­ables growth.

Instacart did some­thing very sim­i­lar: They built their mod­ern search in­fra­struc­ture on Postgres in­stead of run­ning a sep­a­rate search clus­ter. Same story, dif­fer­ent com­pany.

More on the topic: https://​www.post­gresql.org/​docs/​cur­rent/​textsearch.html

PostgreSQL re­places MongoDB: Excellent Json Support

PostgreSQL has ex­cel­lent sup­port for stor­ing and query­ing(!) json. It also fea­tures an in­dex type (GIN) that makes these op­er­a­tions blaz­ingly fast. Is there a need for MongoDB any more?.

The Guardian also wrote an ex­cel­lent ar­ti­cle how they switched from Mongo to PostgreSQL. Thanks for shar­ing Jan-Otto! Hazel also wrote a nice piece on jsonb and what to take into ac­count when us­ing it.

PostgreSQL re­places Kafka and RabbitMQ: PostgreSQL as a queue

Events, queues and per­sis­tent logs are get­ting more and more im­por­tant in to­day’s soft­ware sys­tems. Systems like Kafka, RabbitMQ, SQS and oth­ers pro­vide that func­tion­al­ity. But main­tain­ing them is an­noy­ing, cus­tom and you need the skillset.

The good news: You can just use PostgreSQL. The magic comes from

SELECT .. FOR UPDATE

SELECT .. SKIP LOCKED

Using these SQL fea­tures you can ef­fec­tively use a table as queue. Either in a per­sis­tent fash­ion with a cur­sor and many con­sumers, or in a read-once fash­ion.

The ar­ti­cle at crunchy­data ex­plains this con­cept very well.

My tip: Start with PostgreSQL as a queue­ing sys­tem. Only when that does no longer per­form well switch to other sys­tems like Kafka, RabbitMQ or SQS. You’ll be sur­prised how well PostgreSQL works.

PostgreSQL Replaces Clickhouse: High Volume Time Series Data

Time se­ries data is spe­cial. Often you get many data points in a very short amount of time. And then you have to ag­gre­gate the data fre­quently, do­ing some sta­tis­tics on it and so on.

There are spe­cial­ized soft­ware sys­tems like Clickhouse (amazing by the way…). But you can also use a plu­gin for PostgreSQL that al­lows you to do (nearly) the same: Timescale.

I’ve used Timescale and can rec­om­mend it. The good news is that you can con­tinue us­ing PostgreSQL - even for high vol­ume data eas­ily. No need to learn and main­tain some­thing new.

PostgreSQL as Vector Database for AI Workflows

Timescale lately re­leased the pgvec­tor ex­ten­sion, that turns your PostgreSQL into a vec­tor data­base. This al­lows you to use the tech you al­ready know for in­dex­ing and re­trieval of rel­e­vant data. That’s an es­sen­tial part of AI LLM work­flows.

Timescale also re­cently an­nounced pgai that in­cludes pgvec­tor, but also a lot of other nice ex­ten­sions that make it su­per sim­ple to in­dex data, call LLM mod­els and re­trieve data based on sim­i­lar­ity.

PostgreSQL Replaces Redis: Non-Persistent High Performance Caching

Caching is im­por­tant. Most ap­pli­ca­tions use some­thing like Redis as a cache to get in­for­ma­tion like ses­sions and more quickly. A cache can by de­f­i­n­i­tion lose data and can be re­gen­er­ated from the orig­i­nal source.

But. Why use Redis when PostgreSQL can be tuned to be as fast (in most use­cases) as a Redis cache? The se­cret is us­ing an UNLOGGED table. You can even em­u­late Redis’ au­to­matic ex­pire by a trig­ger. A lot has been writ­ten about this - I can just rec­om­mend try­ing it out.

PostgreSQL Replaces File System: For Raw Data

For one of my clients we had to read and write a huge amount of small pieces of bi­nary en­coded in­for­ma­tion. We ini­tially thought that do­ing this via the file sys­tem was the fastest way to do so.

After some per­for­mance checks it be­came clear that PostgreSQL was even faster than read­ing from the file sys­tem for our use-case. PostgreSQL uses the file sys­tem very ef­fi­ciently for its data - and it adds a lot of caching and ef­fi­cient read­ing and writ­ing strate­gies that can out­per­form writ­ing and read­ing raw data on a file sys­tem.

We used Flatbuffers to store the data in a blob col­umn. Data was then de-se­ri­al­ized on the client. You might want to try that ap­proach as well.

PostgreSQL Replacing Your Graph Database

Hierarchical data can be man­aged in SQL via re­cur­sive queries. That’s ok, but also su­per-hard to read, main­tain and de­bug. Not even speak­ing of per­for­mance.

The bet­ter way is the LTREE datatype of PostgreSQL. It helped me not only once to im­ple­ment hi­er­ar­chi­cal tag struc­tures. Easy to read, main­tain and blaz­ingly fast.

PostgreSQL Replacing Your Microservice

Most of the “microservices” these days are only about mod­els, get­ting data from a data­base and re­turn­ing json to the client.

But you know what? PostgreSQL can turn any query into a Json re­sult. That ef­fec­tively re­places your server mid­dle­ware. There are Pros and Cons to this ap­proach, but it shows the ca­pa­bil­i­ties of PostgreSQL. The amaz­ing Lukas Eder wrote about the topic - not PostgreSQL spe­cific - but every­thing men­tioned there is very well doable in PostgreSQL as well

PostgreSQL - Replacing your Playstation 5

Well. Some en­thu­si­ast im­ple­mented Tetris as Common Table Expressions in pure SQL. Crazy. And maybe not to be taken too se­ri­ously.

Conclusion

The list above is not very ex­haus­tive. PostgreSQL is a very flex­i­ble piece of soft­ware. And it can be ex­tended with plu­g­ins to do more and more.

You need sim­plic­ity if you want to move fast. If you come across a new re­quire­ment al­ways ask: Can’t PostgreSQL do this? And do we re­ally need that shiny new tech­nol­ogy X?

PostgreSQL might not be the an­swer to every­thing - but it is the an­swer to a lot more than you might think!