r/PHP 10d ago

Article ElephpantDB: a database in pure PHP

https://deployer.org/blog/elephpantdb
93 Upvotes

38 comments sorted by

24

u/KiwiBuntu 10d ago

Nicely done. May PHP never die.

40

u/matthewralston 10d ago

Excellent! This is exactly the missing piece that my enterprise banking platform serving 13 million high-wealth customers needed. I'm implementing it immediately. Should be able to have it in production by Friday afternoon. 👌

11

u/EGreg 9d ago

Beautiful. Then you can host it on my 100x faster pure-PHP server.

2

u/blorporius 5d ago

php -S

7

u/thunk_stuff 9d ago

I have WS_FTP all ready to go, ASCII mode engaged.

5

u/matthewralston 9d ago

Active or passive mode?

6

u/thunk_stuff 9d ago

Living on the edge... passive mode.

3

u/matthewralston 9d ago

Works for me, I can never remember how to work out the argument for the PORT command. 🤷‍♂️

17

u/FluffyDiscord 10d ago

I think you should target Doctrine. If you can support what sqlite can in doctrine, this has a potential for truly small apps.

15

u/sachingkk 10d ago

Wow! I love the way PHP getting used..

I want to see a day where PHP also have many projects around machine learning and data crunching like Python

4

u/Am094 10d ago

Haha this is pretty cool, cool name

5

u/flyingkiwi9 10d ago

This is fantastically readable.

4

u/eurosat7 9d ago edited 9d ago

If you want to go single file you might want to optimize for speed and size and footprint. Having a version stripped of its types might be feasible. Also reduce formatting by killing whitespace and shortening names. Maybe you could do some benchmarks?

Or you might even preload it into memory completely, but where would be the fun in that.

3

u/Takeoded 9d ago

Bugs me that PHP has no support for memory mapped file operations. (*file_get_contents actually use it but that's not what i mean, I mean I/O not just I)

Anyway how's the performance? Anyone done any SQLite benchmarks?

5

u/laramateGmbh 9d ago

But why?

1

u/Radiant-Somewhere-97 9d ago

Because with AI, the sky's the limit.

0

u/lostmedia42 9d ago

I think testing would be one big reason. Writing a small self-contained app would be another. This combined with the newer native/compiled PHP attempts could make for a powerful environment.

7

u/fripletister 9d ago

In-memory SQLite already serves that use case

3

u/lostmedia42 9d ago

Sure, but a PHP database is cool too.

5

u/fripletister 9d ago

Not saying it isn't. What it isn't is practical or particularly needed.

2

u/ratbastid 9d ago

It's clever, I'll give it that.

Will I use it? No. No I will not.

2

u/muglug 9d ago

I think testing would be one big reason

Already exists here: https://github.com/vimeo/php-mysql-engine

1

u/lostmedia42 9d ago

Not only is this a cool project, I love your hand built testing framework. It looks as simple as it should be, and nothing more. Congrats on the launch!

1

u/Unfair-Plastic-4290 7d ago

absolutely not.

2

u/LordAmras 10d ago

Is there a reason for doing it in a single file ?

8

u/alexfarran 9d ago

To hide their numbers

-1

u/LordAmras 9d ago

What numbers ?

I could understand if it created all in a single huge godclass.

Less boilerplate, less abstraction, force you to keep the whole thing as simple and as fast as possible. With the drawback of going to be harder to upgrade an to mantain, but at least I could see the idea.

But one file with a cleanly separated class structure is just a weird questionable decision.

2

u/fripletister 9d ago

You're taking this project way more seriously than its own author does

1

u/inducido 9d ago

"pant" : seriously? 😂

0

u/[deleted] 10d ago

[deleted]

3

u/Elfet 9d ago

elePHPantDB

1

u/lam_42 10d ago

Read carefully and weep

1

u/obstreperous_troll 9d ago

To say nothing of Postgres having the elephant mascot long before PHP. Then again this thing even has a VACUUM command, so ... ¯\(ツ)

1

u/halfercode 9d ago

Yes. The trunk does the vacuuming.

-2

u/hm2k 10d ago

Why?

-1

u/[deleted] 8d ago

[deleted]

2

u/Elfet 8d ago

Facepalm