HackerLangs
TopNewTrendsCommentsPastAskShowJobs

b-man

3,808 karmajoined vor 17 Jahren
Believer in individual freedom and debugging.

ebellani -at- gmail -dot- com

http://github.com/ebellani/

Submissions

Why Zulip? Efficient communication with organized team chat

zulip.com
3 points·by b-man·gestern·0 comments

What Nobody Explains About Debezium in 2026 (But Should)

debezium.io
2 points·by b-man·vor 3 Tagen·0 comments

Do you need separate systems when you already have Postgres?

postgresisenough.dev
104 points·by b-man·vor 5 Tagen·86 comments

AI boom risks global financial crash, warn central bankers

telegraph.co.uk
159 points·by b-man·vor 12 Tagen·214 comments

All you need is PostgreSQL

ebellani.github.io
10 points·by b-man·vor 15 Tagen·0 comments

Recruitment and Selection of high performing programmers

ebellani.github.io
2 points·by b-man·vor 16 Tagen·0 comments

Throwing 107 GB and 5B fake rows of order data at DuckDB and Athena

fet.dev
4 points·by b-man·vor 17 Tagen·0 comments

Does AI Adoption Improve Productivity? Effects over the First Three Years

bok.or.kr
2 points·by b-man·vor 17 Tagen·0 comments

The Rise of Single-Node Processing: Challenging the Distributed-First Mindset

pracdata.io
2 points·by b-man·vor 21 Tagen·0 comments

Stretching a point: the economics of elastic infrastructure

ably.com
2 points·by b-man·letzten Monat·0 comments

Watch These Judges Rip into Lawyers for Citing Cases That Don't Exist

404media.co
5 points·by b-man·letzten Monat·0 comments

Writing vs. Shipping: Productivity Effects Across Generations of AI Coding Tools

papers.ssrn.com
3 points·by b-man·letzten Monat·0 comments

Do we fear the serializable isolation level more than we fear subtle bugs (2024)

blog.ydb.tech
88 points·by b-man·letzten Monat·61 comments

Software Development Job Postings are going up in the last year

fred.stlouisfed.org
4 points·by b-man·letzten Monat·1 comments

6M Fake GitHub Stars: How to Vet Open-Source AI Tools

chatgpt.ca
2 points·by b-man·vor 2 Monaten·0 comments

Coalton is an efficient, statically typed Lisp with ideas from Haskell and OCaml

coalton-lang.github.io
203 points·by b-man·vor 2 Monaten·42 comments

The uncritical adoption of AI in science is alarming – We need guard rails

nature.com
4 points·by b-man·vor 2 Monaten·0 comments

State of Code Developer Survey report [pdf]

sonarsource.com
2 points·by b-man·vor 2 Monaten·0 comments

Hallucinated citations are polluting the scientific literature. What can be done

nature.com
4 points·by b-man·vor 2 Monaten·0 comments

An Aristotelian understanding of object-oriented programming

dl.acm.org
2 points·by b-man·vor 2 Monaten·0 comments

comments

b-man
·vor 5 Tagen·discuss
I think your post misses the point of the DBMS centralization: managed consistency.

It is not about ops cost in infrastructure, but ops cost in debugging consistency errors.
b-man
·vor 10 Tagen·discuss


  Location: Brazil (UTC-3, overlaps US hours)
  Remote: Yes
  Willing to Relocate: Yes (US preferred)
  Technologies: SQL Server, DBT, SQL Mesh, PostgreSQL, SQL, OLTP & OLAP, cloud optimization, query optimization, large-table migrations, F#, Clojure, Python, C#, C, Java, Ruby, Rust, Prolog, OCaml, Haskell
  Email: ebellani at gmail
I specialize in rescuing and scaling PostgreSQL systems that have become bottlenecks due to schema debt, growth, or operational complexity. Recent work: re-architected two multi-terabyte OLTP tables (~2TB and ~1TB) handling 200+ writes/sec, improving scalability and reducing application-level complexity.

My work focuses on high-risk database migrations, dangerous schema remediation, hot-path optimization, and making existing systems scale without rewriting the product.

Open to consulting or full-time roles where data is central and performance matters.
b-man
·vor 27 Tagen·discuss


  Location: Brazil (UTC-3, overlaps US hours)
  Remote: Yes
  Willing to Relocate: Yes (US preferred)
  Technologies: SQL Server, DBT, SQL Mesh, PostgreSQL, SQL, OLTP & OLAP, cloud optimization, query optimization, large-table migrations, F#, Clojure, Python, C#, C, Java, Ruby, Rust, Prolog, OCaml, Haskell
  Email: ebellani at gmail
I specialize in rescuing and scaling PostgreSQL systems that have become bottlenecks due to schema debt, growth, or operational complexity.

Recent work: re-architected two multi-terabyte OLTP tables (~2TB and ~1TB) handling 200+ writes/sec, improving scalability and reducing application-level complexity.

My work focuses on high-risk database migrations, dangerous schema remediation, hot-path optimization, and making existing systems scale without rewriting the product.

Open to consulting or full-time roles where data is central and performance matters.
b-man
·letzten Monat·discuss
https://fred.stlouisfed.org/graph/?g=1WPjJ
b-man
·vor 2 Monaten·discuss
have you tried just using emacs? They have an emacs mode https://github.com/coalton-lang/coalton-labs
b-man
·vor 2 Monaten·discuss
Great refs. I think one can find more accessible sources for this knowledge, for instance this course:

https://www.youtube.com/playlist?list=PLoYRQl2t0w0EjRIb9Jr1y...

or Feser's articles such as

- https://www.firstthings.com/article/2013/04/kurzweils-phanta...

- https://edwardfeser.blogspot.com/2019/03/artificial-intellig...
b-man
·vor 3 Monaten·discuss
> The Agile example makes this worse, not better. Yes, Agile was overhyped and badly implemented in many places. But using that to indict the entire movement as Girardian ritual is precisely the logical move the author claims to be critiquing: take some real failures, blame them on a paradigm rather than specific implementations, declare the whole thing rotten. He scapegoats Agile to validate his theory about scapegoating

I don't think the author did that at all. He was fair to interactive development. He specifically points out the scapegoating of waterfall, where the methodology was misrepresented in order to create the space for agile.
b-man
·vor 3 Monaten·discuss
fwiw, your career page seems broken (https://supabase.com/careers)
b-man
·vor 3 Monaten·discuss


   Location: EST
   Remote: Yes 
   Willing to relocate: Yes (US preferred)
   Technologies: PostgreSQL (partitioning, performance, OLTP architecture), SQL, F#, C#, C, Java, Clojure, Common Lisp, Scheme, Emacs Lisp, Python, Ruby, AWS, Linux
   Email: ebellani at gmail
I work on high-throughput systems, especially when they’ve grown into a state where migrations, performance, or schema design have become limiting factors.

Recent work:

Re-architected two multi-terabyte OLTP tables (~2TB and ~1TB) receiving 200+ writes/sec. I focus on “rescue architecture” work: fixing dangerous schemas, stabilizing hot paths, removing app-level complexity, and making Postgres scale without rewriting the product.

Open to consulting or full-time roles where data is core to the business and performance/architecture matters.

Résumé: https://www.linkedin.com/in/eduardo-bellani/ https://ebellani.github.io/
b-man
·vor 4 Monaten·discuss
ocation: EST Remote: Yes Willing to relocate: Yes (US preferred) Technologies: PostgreSQL (partitioning, performance, OLTP architecture), SQL, F#, C#, C, Java, Clojure, Common Lisp, Scheme, Emacs Lisp, Python, Ruby, AWS, Linux

Email: ebellani at gmail

I work on high-throughput PostgreSQL systems, especially when they’ve grown into a state where migrations, performance, or schema design have become limiting factors.

Recent work:

Re-architected two multi-terabyte OLTP tables (~2TB and ~1TB) receiving 200+ writes/sec. I focus on “rescue architecture” work: fixing dangerous schemas, stabilizing hot paths, removing app-level complexity, and making Postgres scale without rewriting the product.

Open to consulting or full-time roles where Postgres is core to the business and performance/architecture matters.

Résumé: https://www.linkedin.com/in/eduardo-bellani/ https://ebellani.github.io/
b-man
·vor 5 Monaten·discuss
Location: EST Remote: Yes Willing to relocate: Yes (US preferred)

Technologies: PostgreSQL (partitioning, performance, OLTP architecture), SQL, F#, C#, C, Java, Clojure, Common Lisp, Scheme, Emacs Lisp, Python, Ruby, AWS, Linux

Email: ebellani at gmail

I work on high-throughput PostgreSQL systems, especially when they’ve grown into a state where migrations, performance, or schema design have become limiting factors.

Recent work:

Re-architected two multi-terabyte OLTP tables (~2TB and ~1TB) receiving 200+ writes/sec. I focus on “rescue architecture” work: fixing dangerous schemas, stabilizing hot paths, removing app-level complexity, and making Postgres scale without rewriting the product.

Open to consulting or full-time roles where Postgres is core to the business and performance/architecture matters.

Résumé: https://www.linkedin.com/in/eduardo-bellani/ https://ebellani.github.io/
b-man
·vor 6 Monaten·discuss
> This is the reason for the push-back against it.

Do you have evidence for that? From memory, it was basically because it was associated with the java/.net bloat from the early 2000s. Then ruby on rails came.
b-man
·vor 6 Monaten·discuss
Location: EST Remote: Yes

Willing to relocate: Yes (US preferred)

Technologies: PostgreSQL (partitioning, performance, OLTP architecture), SQL, F#, C#, C, Java, Clojure, Common Lisp, Scheme, Emacs Lisp, Python, Ruby, AWS, Linux

Email: ebellani at gmail

I work on high-throughput PostgreSQL systems, especially when they’ve grown into a state where migrations, performance, or schema design have become limiting factors.

Recent work:

Re-architected two multi-terabyte OLTP tables (~2TB and ~1TB) receiving 200+ writes/sec. I focus on “rescue architecture” work: fixing dangerous schemas, stabilizing hot paths, removing app-level complexity, and making Postgres scale without rewriting the product.

Open to consulting or full-time roles where Postgres is core to the business and performance/architecture matters.

Résumé: https://www.linkedin.com/in/eduardo-bellani/ https://ebellani.github.io/
b-man
·vor 7 Monaten·discuss
I have written the entire backend of a fintech using nothing but postgresql, integration over http and webhook receival included (the last bit was with postgrest, but you get the point)
b-man
·vor 7 Monaten·discuss
Location: EST

Remote: Yes

Willing to relocate: Yes (US preferred)

Technologies: PostgreSQL (partitioning, performance, OLTP architecture), SQL, F#, C#, C, Java, Clojure, Common Lisp, Scheme, Emacs Lisp, Python, Ruby, AWS, Linux

Email: ebellani at gmail

I work on high-throughput PostgreSQL systems, especially when they’ve grown into a state where migrations, performance, or schema design have become limiting factors.

Recent work:

Re-architected two multi-terabyte OLTP tables (~2TB and ~1TB) receiving 200+ writes/sec. I focus on “rescue architecture” work: fixing dangerous schemas, stabilizing hot paths, removing app-level complexity, and making Postgres scale without rewriting the product.

Open to consulting or full-time roles where Postgres is core to the business and performance/architecture matters.

Résumé: https://www.linkedin.com/in/eduardo-bellani/ https://ebellani.github.io/
b-man
·vor 7 Monaten·discuss
> Not to mention that perfectly normalizing a database always incurs join overhead that limits horizontal scalability. In fact, denormalization is required to achieve scale (with a trade-off).

This is just not true, at least not in general. Inserting on a normalized design is usually faster, due to smaller index sizes, fewer indexes and fitting more rows per page.
b-man
·vor 7 Monaten·discuss
fixed
b-man
·vor 7 Monaten·discuss
Indeed. I was trying to make that point on my concluding paragraph.
b-man
·vor 7 Monaten·discuss
> That may be. What's not specified there is the immense, immense cost of driving a dev org on those terms

I'm happy that we agree on the solution, but disagree only if it is cost worthy. About the cost, I took that into consideration when I wrote the conclusion:

> FAANG-style companies are unlikely to adopt formal methods or relational rigor wholesale. But for their most critical systems, they should. It’s the only way to make failures like this impossible by design, rather than just less likely.

There is an actionable plan in the article. It is possible to run teams like these. It is an economical decision of upper management to run the risk of having these outages vis-a-vis this alternative.
b-man
·vor 7 Monaten·discuss
a fully normalized relation is one where the SQL (say) table in question represents one and only one predicate of your business rules.

It is literally impossible for that to be done automatically. Someone needs to look at the resulting code and confirm that that was the case.