I'd like to hear from those who have used Doctrine 2 (or later) and Propel 1.5 (or later). Most comparisons between these two object relational mappers are based on old versions -- Doctrine 1 versus Propel 1.3/1.4, and both ORMs went through significant redesigns in their recent revisions. For example, most of the criticism of Propel seems to center around the "ModelName Peer" classes, which are deprecated in 1.5 in any case.

Here's what I've accumulated so far (And I've tried to make this list as balanced as possible...):

  • Propel
    • Pros
      • Extremely IDE friendly, because actual code is generated, instead of relying on PHP magic methods. This means IDE features like code completion are actually helpful.
      • Fast (In terms of database usage -- no runtime introspection is done on the database)
      • Clean migration between schema versions (at least in the 1.6 beta)
      • Can generate PHP 5.3 models (i.e. namespaces)
      • Easy to chain a lot of things into a single database query with things like useXxx methods. (See the "code completion" video above)
    • Cons
      • Requires an extra build step, namely building the model classes.
      • Generated code needs rebuilt whenever Propel version is changed, a setting is changed, or the schema changes. This might be unintuitive to some and custom methods applied to the model are lost. (I think?) -- Not true; custom methods aren't lost because the generated class is a base class; Propel provides an entity class specifically for extension.
      • Some useful features (i.e. version behavior, schema migrations) are in beta status.
  • Doctrine
    • Pros
      • More popular
      • Doctrine Query Language can express potentially more complicated relationships between data than easily possible with Propel's ActiveRecord strategy.
      • Easier to add reusable behaviors when compared with Propel.
      • DocBlock based commenting for building the schema is embedded in the actual PHP instead of a separate XML file.
      • Uses PHP 5.3 Namespaces everywhere
    • Cons
      • Requires learning an entirely new programming language (Doctrine Query Language)
      • Implemented in terms of "magic methods" in several places, making IDE autocomplete worthless.
      • Requires database introspection and thus is slightly slower than Propel by default; caching can remove this but the caching adds considerable complexity.
      • Fewer behaviors are included in the core codebase. Several features Propel provides out of the box (such as Nested Set) are available only through extensions.
      • Freakin' HUGE :)

This I have gleaned though only through reading the documentation available for both tools -- I've not actually built anything yet.

I'd like to hear from those who have used both tools though, to share their experience on pros/cons of each library, and what their recommendation is at this point :)

  • Which version of Doctrine are you talking about? v2 and v1.2 are poles apart.
    – Orbling
    Feb 17, 2011 at 1:33
  • 1
    @Orbling: Did you read the title or the body of the question? Read them again :) Feb 17, 2011 at 1:36
  • @Billy ONeal: Good point. Doctrine2 has behaviours removed pretty much entirely from the Core, so I thought you may have been speaking about v1.2 instead.
    – Orbling
    Feb 17, 2011 at 1:41
  • @Orbling: Ah, that makes sense. On the other hand it provides equivalents to "behaviors" -- it just doesn't call them that. Feb 17, 2011 at 2:00
  • @Billy ONeal: It doesn't really, you can implement them yourself in a fairly easy manner, or you can get third-party plugins. But it's not like Doctrine1 or Propel.
    – Orbling
    Feb 17, 2011 at 5:13

6 Answers 6


Dispite the current trend to recommend Doctrine, I need to say otherwise. Keep in mind that also, my personal preferences are oriented to my personal experiences, but how @Dan said, they're both very potent.

I don't like Doctrine for several of the reasons you stated before, like the size and the whole magic methods thingy are the deal breakers with me. So, I use Propel, why? mainly because it's simplicity, and because simple in software development is good. My personal believe is that getting greedy with designs is bad.

Using Propel, I've managed to implement a repository pattern implementation for my own systems, and it works really well, not to mention the performance of Propel, which is one of the fastests ORM I've seen.

So, my basic answer is Propel, because it accomplishes good software with less code and it empowers the IDE to provide you with good intellisense without loosing the point of ORM software which is connecting to the database and doing it nice...

Hope I can help

  • I was using Doctrine for a year. I tried Kohana, Laravel Eloquent, I like their public fields because I really hate getters and setters (I prefer property accessor :P). After I saw the word 'IDE friendly' in Propel, I decided to try Propel tonight.
    – Zorji
    Sep 14, 2015 at 5:20

Your information about Doctrine 2 is wrong...

  • DQL is pretty much SQL, so not much to learn.
  • Doctrine 2 doesn't use any 'magic' (only what you'd expect in any up-to-date PHP library).
  • Doctrine 2 doesn't actively do database introspection... mapping is stored in your entities/mapping files and it assumes your database will fit to that.
  • Caching is hardly 'considerable complexity'.
  • Doctrine 2 has no 'behaviours' out-of-the-box

I haven't used Propel before, but Doctrine 2 is much newer and has a really high quality codebase. But it looks like Propel uses Active Record, Doctrine 2 uses the Data Mapper pattern.

The downside of Doctrine 2 being newer is the lack of third-party examples, but it's quickly building up.

I recommend Doctrine 2...

  • If you haven't used Propel before than I have no choice but to downvote this due to being FUD. As for the "Magic" comment, what I mean is that it is based on PHP magic methods such as __get and __set (which is true) rather than real methods. Mar 30, 2011 at 3:23
  • 1
    Ok for the down vote... But where does Doctrine 2 use magic methods? Aside DocumentRepository's find* methods (__call), but that's not a problem because it's just a nicer way of querying... you'll always lose the IDE autocompletion. If you want ActiveRecord use Propel. If you want Data Mapper, use Doctrine 2.
    – Cobby
    Mar 30, 2011 at 4:33
  • 2
    Propel doesn't introspect database at runtime thanks to code generation. Nov 2, 2011 at 18:24
  • Bullet item #1 is not entirely correct, DQL is not "pretty much" like SQL. DQL depends on the fact that you are referencing model objects which Doctrine must be aware of, and there are some complications if more complex joins are necessary. Jul 26, 2012 at 16:36
  • 2
    DQL is a dialect of SQL, how does that not make it "pretty much" like SQL? Yes, the semantics of the language a little different (objects vs. tables), but ultimately DQL is language for querying structured data - which just happened to be represented as objects not tables - a.k.a SQL.
    – Cobby
    Jul 27, 2012 at 4:54

I recommend you Propel because it's well integrated, fast, and powerful. To generate code is better than to load classes on runtime, it eases debug steps and shows you what you've created. So the build step is not à problem.

Doctrine2 has no official behaviors, and the DataMapper design pattern is cool but hard to use in real life. Oh and DQL is a pain, yet aborder language to learn...

If you want to think with objects (no DQL/SQL/whatever), choose Propel.

Doctrine2 is part of Symfony2 de facto but things will move very soon, look at the last Fabien Potencier article.

Cheers, William

  • 1
    ,i started with Propel 2years ago with symfony1 .then had to switch to Doctrine2 for symfony2. Happy to go back to Propel.Cheers! Nov 17, 2012 at 5:25

From your comments, it sounds like you are trying to pick Propel or Doctrine to replace or fulfill your need for an ORM in a legacy application.

That being said, I think it's important to not lose sight of the fact that moving to either one could be a great improvement to your application. So, there's no real wrong answer.

Therefore, the solution you pick is largely up to your preferences based on you answers to the following questions:

  1. Which one best integrates into your current solution?
  2. Which API to you prefer?
  3. Which one would you rather contribute to? (patches, documentation, bug reports, etc...)

Personally, I would recommend Doctrine 2 because of it's community, documentation, and architecture.

  • 1
    I'm looking for a comparison between them here though. (Why does which one I'd rather contribute to matter? I don't want to contribute to any of them -- I want to use the library, not write it! ;) ). You're saying Doctrine 2 has good community, docs, and architecture -- architecture-wise, yes, it's DataMapper. Docs wise I'm not sure I agree -- both projects seem to have good docs. I've not seen much of a community using either system. Would you care to elaborate on what you mean by these things? Mar 30, 2011 at 21:29
  • 2
    Oh you like the Doctrine doc ? Did you read the Propel one ? And yeah the Doctrine community is nice but take a look at the ODM repository, a lot of PRs aren't even commented nor merged nor rejected… Look at the Propel timeline, the community is really active ;) Nov 2, 2011 at 12:53

I chose Propel 1.63 for a large legacy mysql application (200 tables or so) - the factors here included: IDE support that enables new developers to find their way easily with code completion; cross database schema support, performance; better native support for enums and the use of several behaviours. Actually I started with Doctrine since this was the best supported by Symfony2 but once Propel vastly improved their support with Symfony (the next platform I will eventually migrate to) I switched due to the better handling of above issues. No regrets at all Propel is a decisive winner.


They are both very good. There are some edge cases in which one can do something, or do something better, than the other one. Wherever I've experienced problems with either, it was due more to my lack of knowledge than something they could not do.

This means that documentation and support is more important than intrinsic ability of the code. Do you know anyone who can help you when you run into problems? How well do you get on with the documentation? Does one of them just 'feel' more natural to yoU?

Not the answer you're looking for? Browse other questions tagged or ask your own question.